From Preetida.Vinayakray-Jani@nokia.com Tue Apr 2 13:05:42 2002 From: Preetida.Vinayakray-Jani@nokia.com (Preetida.Vinayakray-Jani@nokia.com) Date: Tue, 2 Apr 2002 16:05:42 +0300 Subject: [eap] EAP state machine Message-ID: Hello: In EAP Peer state Machine there is one procedure named 'policySatified' = which determines the next transition is Success or not. Similarly on = Authenticator it determines whether to deliver success msg. or not. = Assuming that Authenticator site policy is satisfied and it has = delivered the success message. Now if on peer site the success message = is not arrived in allowable time then what will be subsequent = transition? failure? i.e. once again the initPolicy()? I am somewhat = confused here.=20 thanks, Preeti From bdpayne@cs.umd.edu Tue Apr 2 15:45:12 2002 From: bdpayne@cs.umd.edu (Bryan D. Payne) Date: Tue, 2 Apr 2002 10:45:12 -0500 (EST) Subject: [eap] Issue #3: No state machine In-Reply-To: Message-ID: > > In this case, the authenticator could simply time > > out and send a success / failure message. > > If no response is received, a timeout will occur -- but the behavior of > existing implementations would be to drop the connection. Sending another > packet isn't possible because RADIUS servers don't retransmit. Since the > NAS hasn't received a response, it can't send an Access-Request to the > RADIUS server, and therefore the connection will stall. Hmmm...but only the new implementations would have to deal with the timeout issue. The old implementations would never need to worry about that because they wouldn't be sending this new message. However, I do see that this would lead to problems with a type of downgrade attack. That is, an authenticator could always run the older version of the protocol (using just success / failure messages) if it wanted to do something malicous. Backwards compatibility can certainly be a pain sometimes... ;-) > I think the issue is not with silent discard, but in the fact the > retransmission behavior. Perhaps the original idea (making these new messages part of the normal request / reply structure) is still the best for backwards compatibility. I'll think about how this can be represented in the state machine. -bryan From dpotter@cisco.com Wed Apr 3 16:27:51 2002 From: dpotter@cisco.com (Darran Potter) Date: Wed, 3 Apr 2002 17:27:51 +0100 Subject: [eap] Draft EAP BOF Minutes In-Reply-To: <5.1.0.14.0.20020328022958.00a8c870@pop.theworld.com> Message-ID: > What is needed is a simple peer-review communal process. > Open publication, gather feedback from the group, and have a designated > moderator to help resolve disputes (and squelch the occasional > rude remarks). > If no new criticism arrives within a designated period, off it goes. > This is sort of what I was hoping for, albeit my original mail was clumsy. ..and Im not looking for a critique (read "slagging-off") of MS-CHAP per se. I do want to make sure that we haven't introduced any new problems. If anyone has some constructive comments I would be pleased to receive them and incorporate any required changes where necessary. Darran From aboba@internaut.com Fri Apr 5 07:22:19 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 4 Apr 2002 23:22:19 -0800 (PST) Subject: [eap] Re: [issue 7] Ability to authentication with multiple methods Message-ID: Had an interesting question come up. What happens when, in the middle of one EAP method, a Peer receives a Request for a completely different EAP method. Does it silently discard the packet? Call the new EAP method while leaving the old one suspended? Nak the new method with the Type of the previous one? Any opinions? Here are my thoughts: a. I think that once an EAP Type Request is received by the Peer, that the Peer requires that EAP method accomplish its purpose. For example, if the method offers mutual authentication, then the server should authenticate itself to the Peer before starting a new method. So it seems to me that the Peer can't leave the state machine of the EAP Type until its policy with respect to that Type is satisfied. Otherwise, it would always be possible to abort a Type simply by sending a packet for yet another EAP Type. My take is that if the policy is not satisfied, that the packet for the new Type is silently discarded. This would prevent an attacker from spoofing a packet for a new Type in the middle of a conversation and moving the Peer out of the state machine for the previous Type. From aboba@internaut.com Fri Apr 5 07:33:29 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 4 Apr 2002 23:33:29 -0800 (PST) Subject: [eap] Re: [issue 18] Identifier behavior details Message-ID: RFC 2284 only appears to require that the Identifier change on a new Request, and stay the same on a retransmitted Request as well as in the Response to that Request. It doesn't say anything about the Identifier being unique for every new Request within an EAP conversation. And it doesn't say anything about what an Authenticator does on receiving a Response not corresponding to a Request or what a Peer does on receiving multiple Requests with different Identifiers. Here are my thoughts: a. The Identifier field is only a single octet. This makes it really easy to guess, even if the implementation doesn't increment the Identifier with each new Request, which most implementations seem to do. Since the Identifier is so easy to guess, it is easy for an attacker to insert packets that can disrupt the EAP Peer state machine. Say I don't want the Peer to see packet with Identifier #4. The attacker can just send a packet with this Identifier before the real one arrives. If duplicate Requests are automatically discarded by the Peer, then the real packet will never be processed. So I think the right answer is for the Peer to Respond to the Request, provided that it makes sense, but not to do its own duplicate elimination before validating the packet. Similarly, on the Authenticator side, if duplicates are eliminated prior to checking packet validity, then an attacker only needs to guess the Identifier (easy to do since it is the same as the Request), insert a Response and the real Response will never be processed, so that the conversation aborts. Some questions: a. Does it help if the Identifier is randomly chosen and then can wrap? I think not, since the space is so small that it really doesn't make much difference. b. Should we formally require that the Identifier be incremented with each new request? This removes some flexibility, but still probably enables everything that could be done otherwise. From aboba@internaut.com Fri Apr 5 07:42:50 2002 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 4 Apr 2002 23:42:50 -0800 (PST) Subject: [eap] Proposed issue resolutions Message-ID: RFC 2284bis-04 straw man is now available at: http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-04.txt Current open and resolved issues are at: http://www.drizzle.com/~aboba/EAP/eapissues.html Here are some of the issues it proports to resolve: Issue #11 : no threat model Rewrote the security considerations section. Issue #12: no support for localization UTF-8 is now required in displayable messages, including Notification and Identity-Request. Issue #17: Negotiation This is a good idea and probably should be handled via creation of a new EAP method. It therefore should be handled as a separate document and does not require changes to RFC 2284bis. Marked as a Reject. From bdpayne@cs.umd.edu Fri Apr 5 12:52:26 2002 From: bdpayne@cs.umd.edu (Bryan D. Payne) Date: Fri, 5 Apr 2002 07:52:26 -0500 (EST) Subject: [eap] Re: [issue 7] Ability to authentication with multiple methods In-Reply-To: Message-ID: I agree, and this is how it is represented in the currently proposed state machine. -bryan On Thu, 4 Apr 2002, Bernard Aboba wrote: > Had an interesting question come up. What happens when, in > the middle of one EAP method, a Peer receives a Request for > a completely different EAP method. Does it silently discard > the packet? Call the new EAP method while leaving the > old one suspended? Nak the new method with the Type of > the previous one? > > Any opinions? > > Here are my thoughts: > > a. I think that once an EAP Type Request is received by the Peer, that the > Peer requires that EAP method accomplish its purpose. For example, if the > method offers mutual authentication, then the server should authenticate > itself to the Peer before starting a new method. So it seems to me that > the Peer can't leave the state machine of the EAP Type until its policy > with respect to that Type is satisfied. Otherwise, it would always be > possible to abort a Type simply by sending a packet for yet another EAP > Type. > > My take is that if the policy is not satisfied, that the packet for the > new Type is silently discarded. This would prevent an attacker from > spoofing a packet for a new Type in the middle of a conversation and > moving the Peer out of the state machine for the previous Type. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From bdpayne@cs.umd.edu Fri Apr 5 12:55:50 2002 From: bdpayne@cs.umd.edu (Bryan D. Payne) Date: Fri, 5 Apr 2002 07:55:50 -0500 (EST) Subject: [eap] Re: [issue 18] Identifier behavior details In-Reply-To: Message-ID: > So I think the right answer is for the Peer to Respond to the Request, > provided that it makes sense, but not to do its own duplicate elimination > before validating the packet. > > Similarly, on the Authenticator side, if duplicates are eliminated prior > to checking packet validity, then an attacker only needs to guess the > Identifier (easy to do since it is the same as the Request), insert a > Response and the real Response will never be processed, so that the > conversation aborts. How can the peer or authenticator ever truely validate a packet? Since we have no cryptographic protection of packets, one can easily spoof packets without detection, right? -bryan From aboba@internaut.com Fri Apr 5 14:49:57 2002 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 5 Apr 2002 06:49:57 -0800 (PST) Subject: [eap] Re: [issue 18] Identifier behavior details In-Reply-To: Message-ID: > > So I think the right answer is for the Peer to Respond to the Request, > > provided that it makes sense, but not to do its own duplicate elimination > > before validating the packet. > > > > Similarly, on the Authenticator side, if duplicates are eliminated prior > > to checking packet validity, then an attacker only needs to guess the > > Identifier (easy to do since it is the same as the Request), insert a > > Response and the real Response will never be processed, so that the > > conversation aborts. > > How can the peer or authenticator ever truely validate a packet? Since we > have no cryptographic protection of packets, one can easily spoof packets > without detection, right? Some methods *do* have cryptographic protection (PEAP, TTLS). So the question is whether they get to validate the packet, or whether duplicate elimination throws it away before they get the chance. The latter approach seems dangerous because then an invalid packet could cause a valid one to be thrown away. From sjosefsson@rsasecurity.com Sun Apr 7 11:35:31 2002 From: sjosefsson@rsasecurity.com (Simon Josefsson) Date: Sun, 07 Apr 2002 12:35:31 +0200 Subject: [eap] RFC 2284bis status In-Reply-To: (Bernard Aboba's message of "Sat, 30 Mar 2002 21:59:07 GMT") References: Message-ID: Bernard Aboba writes: > http://www.drizzle.com/~aboba/EAP/draft-ietf-pppext-rfc2284bis-03.txt Quoting new text in the security consideration, section 9.1: ,---- | However, where EAP is run over wireless media such as IEEE 802.11, or | over IP, such as within protocols supporting PPP or Ethernet tunneling | [RFC2661], this assumption is no longer valid and the vulnerability to | attack is much greater. As a result, when EAP is used with wireless | media or over IP, the EAP conversation SHOULD be authenticated, | integrity protected and encrypted, on a per-packet basis. This can be | accomplished using mechanisms such as ISAKMP [RFC2408], as is done in | PIC [PIC], or using TLS [RFC2246]. `---- What are the implications of this? Is this text suggesting that EAP should not be used directly over WLAN without protection? The EAP Success and EAP Reject messages are not protected, even if the EAP mechanism used supports per-packet auth/integrity/encryption. Also, is it strictly necessary that the conversation is encrypted? It seems that an authentication protocol could do without encryption and still be considered secure. Thanks, Simon From aboba@internaut.com Tue Apr 9 02:39:05 2002 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 8 Apr 2002 18:39:05 -0700 (PDT) Subject: [eap] Proposed resolution to EAP issue #16 Message-ID: I have come up with the following text for RFC2869bis, to resolve EAP Issue #16 and Diameter issue #300. Comments welcome. Diameter issues: http://www.drizzle.com/~aboba/AAA/issues.html EAP issues: http://www.drizzle.com/~aboba/EAP/eapissues.htmlA 2.5. Usage guidelines 2.5.1. Conflicting messages In some cases, the authentication result implied by the encapsulated EAP packet may not match the result communicated in the RADIUS message. For example, and EAP Failure packet may be encapsulated within an Access- Accept message and an EAP Success packet may be encapsulated within an Access-Reject. Alternatively, no EAP-Message attribute may be included within an Access-Accept or Access-Reject. Such combinations are likely to cause confusion, because the NAS and Peer will arrive at different conclusions as to the outcome of the authentication. For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the Peer. However, on receiving the Success, the Peer will be lead to believe that it authenticated successfully. Similarly, if the NAS receives an Access- Accept with an encapsulated EAP Failure, it will grant access to the Peer. However, on receiving a Failure, the Peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the Peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access. As described in [RFC2284bis], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore no further Access-Requests will be sent to the RADIUS server. As a result, the NAS will not be given an indication of whether to Allow or Deny access while the Peer will be informed as to the outcome of the authentication. To avoid these conflicts, the RADIUS server SHOULD check to make sure that the results implied by an encapsulated EAP-Message attribute and the RADIUS message are in agreement. The following combinations SHOULD NOT be sent by a RADIUS server as part of an EAP conversation: Access-Accept/EAP-Message/EAP-Failure Access-Accept/no EAP-Message attribute Access-Reject/EAP-Message/EAP-Success Access-Reject/no EAP-Message attribute Access-Challenge/EAP-Message/EAP-Success Access-Challenge/EAP-Message/EAP-Failure Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. 2.5.2. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, the NAS SHOULD process EAP-Message attributes last. 2.5.3. Displayable messages The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284bis]. However, when sent during an EAP conversation, displayable messages SHOULD be encapsulated within an EAP-Message/Notification-Request rather than within a Reply-Message attribute. While a NAS receiving a Reply-Message attribute MAY send an EAP Notification-Request to the peer, several issues may arise from this: [1] Unexpected Notification-Responses. On receiving an EAP Notification-Request, the EAP Peer will send a Notification- Response, and the NAS will pass this on to the RADIUS server, encapsulated within an EAP-Message attribute. Since the RADIUS server may not be expecting a Notification-Response, it may silently discard the packet. [2] Identifier conflicts. While the Notification-Request contains an an Identifier, a Reply-Message attribute does not. As a result, a NAS receiving a Reply-Message and wishing to translate it to a Notification-Request will need to make up an Identifier. Since the NAS cannot make assumptions about how the RADIUS server chooses Identifiers, it is possible that the chosen Identifier will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. As noted in [RFC2284bis] this would violate the requirement that Identifier values be unique within an EAP conversation. 2.5.4. Multiple EAP-Message attributes An Access-Challenge, Access-Accept, Access-Reject or Access-Request message MAY contain zero or more EAP-Message attributes. However, where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to to form a single EAP packet. Since EAP is a "lockstep" protocol, a new EAP-Request cannot be sent until an EAP-Response is received to an outstanding request and only a single Request can be outstanding at a given time. As a result, multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request message. In addition, since a Reply-Message attribute MAY be translated to a Notification-Request by some NASes, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. From bonacci@ascend.com Sat Apr 13 01:29:55 2002 From: bonacci@ascend.com (tom bonacci) Date: Fri, 12 Apr 2002 18:29:55 -0600 Subject: [eap] User-Name in EAP/RADIUS - String? Message-ID: <3CB77BE5.9BDDC079@ascend.com> Please help clear up an ambiguity: from RFC 2869: > In order to permit non-EAP aware RADIUS proxies to forward the > Access-Request packet, if the NAS sends the EAP-Request/Identity, the > NAS MUST copy the contents of the EAP-Response/Identity into the > User-Name attribute and MUST include the EAP-Response/Identity in the > User-Name attribute in every subsequent Access-Request. 1) Is the EAP-Response/Identity (as concerns 2869), which is required to be placed into the User-Name attribute, the entire EAP-Response/Identity packet including Code, Identifier, Length, Type, and Type-Data or is it simply the Type-Data? (If the latter is true, 2869 might more carefully have been written: "...the NAS MUST copy the contents of Type-Data from the EAP-Response/Identity packet into the User-Name attribute...") 2) RFC 2865 defines the User-Name attribute to be the triple: > User-Name (0x01), Length (>3), and String... RFC 2284 makes no demands upon the contents of Type-Data contained in an EAP-Response/Identity. RFC 2284 would seem to allow any data, including embedded 0x00's (and, in fact, this might be thought useful by some EAP authentication schemes). Does EAP interoperation with RADIUS, as defined in 2869, presuppose that the contents of Type-Data within an EAP-Response/Identity packet be somewhat well-behaved (i.e. - a reasonable string)? Thanks for any responses. regards, Tom Bonacci Lucent Technologies/Bell Labs Innovations From aboba@internaut.com Sun Apr 14 19:15:43 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 14 Apr 2002 11:15:43 -0700 (PDT) Subject: [eap] Re: [Issue 19] User-Name in EAP/RADIUS In-Reply-To: <200204131617.g3DGH4w14548@internaut.com> Message-ID: I've assigned this issue #19. EAP issues are tracked at: http://www.drizzle.com/~aboba/EAP/eapissues.html > from RFC 2869: > > In order to permit non-EAP aware RADIUS proxies to forward the > > Access-Request packet, if the NAS sends the EAP-Request/Identity, the > > NAS MUST copy the contents of the EAP-Response/Identity into the > > User-Name attribute and MUST include the EAP-Response/Identity in the > > User-Name attribute in every subsequent Access-Request. > > > 1) Is the EAP-Response/Identity (as concerns 2869), which is required to > be placed into the User-Name attribute, the entire EAP-Response/Identity > packet including Code, Identifier, Length, Type, and Type-Data or is it > simply the Type-Data? (If the latter is true, 2869 might more carefully > have been written: "...the NAS MUST copy the contents of Type-Data from > the EAP-Response/Identity packet into the User-Name attribute...") It is simply the Type-Data. Your recommended change will be incorporated in RFC2869bis-02. > 2) RFC 2865 defines the User-Name attribute to be the triple: > > User-Name (0x01), Length (>3), and String... > RFC 2284 makes no demands upon the contents of Type-Data contained in an > EAP-Response/Identity. RFC 2284 would seem to allow any data, including > embedded 0x00's (and, in fact, this might be thought useful by some EAP > authentication schemes). Does EAP interoperation with RADIUS, as > defined in 2869, presuppose that the contents of Type-Data within an > EAP-Response/Identity packet be somewhat well-behaved (i.e. - a > reasonable string)? > In RFC 2284bis-04, the following text describes the contents of the Type-Data field of the Identity type: "This field MAY contain a displayable message in the Request, containing UTF-8 encoded 10646 characters [RFC2279]. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." Note that some similar text about UTF-8 has been put into the description of the Notification type. Any problems with this? From aboba@internaut.com Sun Apr 14 20:06:45 2002 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 14 Apr 2002 12:06:45 -0700 (PDT) Subject: [eap] Issue 20: Reply-Message or Notification within Access-Accept/Reject Message-ID: Issue 20: Reply-Message or EAP-Request/Notification attribute within Access-Accept or Access-Reject Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 14, 2002 Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html Document: RFC2869bis-01 Comment type: T Priority: S Section: 2.5 Rationale/Explanation of issue: If an EAP-Message/EAP-Request/Notification attribute is sent within an Access-Accept or Access-Reject, then the Peer is likely to reply with an EAP-Response/Notification, and the NAS will pass this back to the RADIUS server as an Access-Request/EAP-Message/EAP-Response/Notification. Since an Access-Accept or Access-Reject terminates the RADIUS conversation, this will be unexpected. The same thing is true of a Reply-Message attribute sent within the Access-Accept or Access-Reject, assuming that we allow a NAS to translate this to an EAP-Request/Notification. Change: Add the following text to section 2.5: "The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284bis]. However, during an EAP conversation, the RADIUS server SHOULD encapsulate displayable messages within an EAP-Message/EAP-Request/Notification, rather than within a Reply-Message attribute. While a NAS receiving a Reply-Message attribute within an EAP conversation MAY copy the value of the Reply-Message attribute into the Type-Data of an EAP-Request/Notification and send this to the Peer, several issues may arise from this: [1] Unexpected Responses. On receiving an EAP-Request/Notification, the EAP Peer will send an EAP-Response/Notification, and the NAS will pass this on to the RADIUS server, encapsulated within an EAP-Message attribute. However, the RADIUS server may not be expecting an EAP-Response/Notification. For example, consider what happens when a Reply-Message attribute is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute present. If the value of the Reply-Message attribute is copied into the Type-Data of an EAP-Request/Notification and sent to the peer, this will result in an Access-Request containing an EAP-Message/EAP-Response/Notification attribute being sent by the NAS to the RADIUS server. Since an Access-Accept or Access-Reject message terminates the RADIUS conversation, such an Access-Request would not be expected. [2] Identifier conflicts. While the EAP-Request/Notification contains an an Identifier, a Reply-Message attribute does not. As a result, a NAS receiving a Reply-Message and wishing to translate this to an EAP-Request/Notification will need to make up an Identifier. Since the NAS cannot make assumptions about how the RADIUS server chooses Identifiers, it is possible that the chosen Identifier will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. As noted in [RFC2284bis] this would violate the requirement that Identifier values be unique within an EAP conversation. Multiple EAP-Message attributes An Access-Challenge, Access-Accept, Access-Reject or Access-Request message MAY contain zero or more EAP-Message attributes. However, where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to to form a single EAP packet. Since EAP is a "lockstep" protocol, a new EAP-Request cannot be sent until an EAP-Response is received to an outstanding request and only a single Request can be outstanding at a given time. As a result, multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request message. Within an EAP conversation a Reply-Message attribute MAY be translated to an EAP-Request/Notification. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. EAP-Message/EAP-Request/Notification or Reply-Message attributes SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation. From salga@bell-labs.com Mon Apr 15 22:00:20 2002 From: salga@bell-labs.com (Luca Salgarelli) Date: 15 Apr 2002 17:00:20 -0400 Subject: [eap] Latest EAP-SKE draft Message-ID: <1018904428.10675.33.camel@valjean> Hi. I'd like to announce the availability of a revised draft on EAP-SKE. It should appear shortly on the IETF ID directories. In the meanwhile, you can grab it at: http://www.bell-labs.com/user/lsalgarelli/id/draft-salgarelli-pppext-eap-ske-01.txt Comments are welcome. Thanks Luca From bdpayne@cs.umd.edu Wed Apr 17 21:32:59 2002 From: bdpayne@cs.umd.edu (Bryan D. Payne) Date: Wed, 17 Apr 2002 16:32:59 -0400 (EDT) Subject: [eap] Updated state machine document Message-ID: I just posted an updated version of the EAP state machine paper. You can find it at: http://www.cs.umd.edu/~bdpayne/papers/eap.txt Changes include updates to the state machine diagrams and updates in the text regarding timeouts and requirements for the authMethodSuccess and authMethodFailure state machine variables. -bryan From Luciana.Costa@TILAB.COM Fri Apr 19 17:06:05 2002 From: Luciana.Costa@TILAB.COM (Costa Luciana) Date: Fri, 19 Apr 2002 18:06:05 +0200 Subject: [eap] EAP-TLS Message-ID: Hi,=20 I have some question about the EAP-TLS Authentication.=20 I understand that EAP-TLS provides mutual-authentication between the client wireless and the server RADIUS. During authentication the server presents a certificate with a public key to the client. The client generate a premaster_secret, encrypted it with the public key in the server certificate and transmitted it to the server. The server decrypted the premaster_secret with his private key. Then the server and the client convert the premaster_secret in a master_secret. My questions are: * How is generate the unicast key from the master secret, by the server and the client? Is the unicast key then used with Inizialization Vector to derive the WEP key? * How is performed authentication with the certificate. I know the server send his certificate and the client send him his certificate. But how they prove their identity? For the authentication is necessary that the certificate has a signature key? * The multicast/broadcast key generated by the Access Point are encrypted with the session key that the server send to the Access Point. Are used the multicast key to encrypt the multicast traffic send from the AP to multiple wireless client? Can you give me some examples of broadcast traffic that needed to be encrypted with broadcast WEP key? * Finally how is performed the client roaming from the point of authentication view? You help will be appreciated. Luciana Costa From aboba@internaut.com Thu Apr 25 02:37:05 2002 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 24 Apr 2002 18:37:05 -0700 (PDT) Subject: [eap] Re: EAP state machine In-Reply-To: Message-ID: Note that this transition may also be defined within another spec (e.g. IEEE 802.1X) so that specifying it in RFC2284bis as well could result in contradictions. On Tue, 2 Apr 2002 Preetida.Vinayakray-Jani@nokia.com wrote: > Hello: > > In EAP Peer state Machine there is one procedure named 'policySatified' which determines the next transition is Success or not. Similarly on Authenticator it determines whether to deliver success msg. or not. Assuming that Authenticator site policy is satisfied and it has delivered the success message. Now if on peer site the success message is not arrived in allowable time then what will be subsequent transition? failure? i.e. once again the initPolicy()? I am somewhat confused here. > > thanks, > > Preeti >