One reason often discussed on this list is that the passwords are not stored in clear text or some other format that can be used with these protocols.
> -----Original Message----- > From: Dan Harkins [mailto:[email protected]] > Sent: Thursday, June 24, 2010 4:25 PM > To: Joseph Salowey (jsalowey) > Cc: Dan Harkins; Alan DeKok; [email protected]; Sam Hartman > Subject: RE: [Emu] Channel Binding Discussion at IETF 77: why bother > > > Hi Joe, > > Why would someone go to the expense to implement EAP-TTLS or EAP-FAST > but not also do some hash-a-password-with-nonces method like GPSK or > MSCHAPv2 that proves to the client that the server knows the password? > The only reason I can see to do PAP inside EAP-TTLS or EAP-FAST is > when using a token card or other OTP. What other reason would > someone do this? It's like driving a horse-drawn carriage instead > of a car-- "why are you still using this failed technology?" (Apologies > to the Amish on this list). > > Dan. > > On Thu, June 24, 2010 3:45 pm, Joseph Salowey (jsalowey) wrote: > > There are many deployments of Tunneled EAP methods (EAP-TTLS, EAP-FAST) > > where a password is sent from the client to the Authentication server > > within the protected tunnel. Terminating the tunnel somewhere other > > than the home server would be bad as it would disclose this long term > > secret. > > > > Joe > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf Of > > Dan > >> Harkins > >> Sent: Thursday, June 24, 2010 3:07 PM > >> To: Alan DeKok > >> Cc: [email protected]; Sam Hartman > >> Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother > >> > >> > >> On Thu, June 24, 2010 1:55 pm, Alan DeKok wrote: > >> > Dan Harkins wrote: > >> >> The only type of credential that would have the issues you're > >> >> talking about is a long-term password used in PAP. Now I'm not > >> >> a big OPS guy but I do have quite a bit of experience in actual > >> >> deployments of 802.1X and EAP and I haven't seen them used > > anywhere. > >> > > >> > TTLS is in wide-spread use in many environments. > >> > > >> >> If someone has a long-term password they're doing EAP-MSCHAPv2. > >> > > >> > I disagree with such a blanket statement. > >> > >> I disagree with disagreements that do not provide any justification > >> for disagreement. > >> > >> >> If someone's doing PAP they're using a token card or some type of > >> >> OTP. > >> > > >> > See above. > >> > >> See above. > >> > >> >> Are you worried about a AAA proxy hijacking a client's OTP > >> >> and impersonating it? To what effect? An fake billing? Can't this > >> >> proxy engage in fraud with the client's MSK as well? Are you > > worried > >> >> about a AAA proxy doing an off-line dictionary attack against > > MSCHAPv2? > >> > > >> > It's bad security practice to expose information that doesn't need > > to > >> > be exposed. > >> > >> No, what's bad security practice is to expose a secret which allows > >> an attacker to completely void the security practices engaged in by > > the > >> client and NAS! Either a proxy is trusted (to see information that is > >> hidden from those who are not trusted) or it's not. You can't have it > >> both ways. > >> > >> >> Just out of curiosity, though, how do you propose to prevent > >> >> a proxy from seeing an MS-CHAPv2 exchange or an OTP fly by? > >> > > >> > The tunnel methods currently in use terminate the TLS tunnel at > > the > >> > home AAA server. No proxy sees the MS-CHAPv3 or OTP exchange. > >> > >> I disagree with such blanket statements. I know of implementations > >> of EAP tunnel methods by such vendors as Cisco that do otherwise. The > >> freeware hostapd software does too. Evidence abounds to contradict > >> you blanket statement. > >> > >> >> These > >> >> tunnel methods typically terminate in devices that are also AAA > >> >> clients, and that's because people want to do this sort of thing-- > >> >> terminate the tunnel locally and then forward the client's > > credential > >> >> on to some central clearing house for a yea or nea. > >> > > >> > Can you describe a system in wide-spread use that does this? My > >> > experience has been that this practice is rare. It is generally done > >> > only within the home AAA domain, in order to enable > > inter-operability > >> > with AAA servers that don't do EAP. > >> > >> Every wireless switch product I know of has a feature where the > >> tunnel is terminated on the switch and the "inner method" can go > >> elsewhere if so configured. Look at PEAP. It's standard in the most > >> prevalent laptop software around and what are it's "inner methods"? > >> Well there's EAP-MSCHAPv2 and EAP-TLS. In other words, it's another > >> EAP method. And the client is speaking EAP inside of EAP because that > >> allows the "inner method" to be terminated somewhere else. > >> > >> Notice how the tunnel method requirements document talks about "the > >> inner EAP method"? It's an EAP method, not just some credential > > exchange, > >> and being an EAP method it can be sent to another device. How do you > >> propose that "the inner EAP method" terminate at the same place as the > >> tunnel? > >> > >> Can you describe current deployments of tunnel methods that > > terminate > >> everything, EAP-TLS plus some client credential authentication, at the > >> home AAA server? > >> > >> >> Do you want to > >> >> prohibit an "inner method" from terminating on a different entity > >> >> than the "outer (tunnel) method"? > >> > > >> > I think the messages are clear. Speculation as to additional > > intent > >> > is not necessary. > >> > >> No, the message Sam communicated was not clear. He stated a problem > >> and the implication of "fixing" that "problem" is, itself, a problem. > >> I'm not speculating on anything. I'm asking a simple question. Since > >> you agree with Sam on this then why don't you answer it? > >> > >> Alan, do you want to prohibit an "inner method" from terminating on > > a > >> different entity than the "outer (tunnel) method"? If the answer is > > yes > >> then I have no further questions. If the answer is no then I'd like to > >> know how you intend on keeping the contents of that "inner method" > > away > >> from the prying eyes of these proxy attackers? > >> > >> Dan. > >> > >> > >> > >> _______________________________________________ > >> Emu mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/emu > > > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
