Why can't have another EAP tunnel terminated at home authentication server inside EAP-TTLS tunnel terminated at the visited network to protect password end-to-end (besides additional tunneling overhead, of course)?
Yoshihiro Ohba (2010/06/25 7:45), 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 > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
