Joe, I'm sorry I'm being so dense.
What is the nature of this transformed password such that it cannot be used in those protocols yet it's still a long-term credential whose disclosure in PAP would be tragic? That doesn't sound like a OTP or a token card since those aren't long-term credentials, and it doesn't sound like the transform is some one-way function because the output of those can be used in the protocols described below. So I'm stumped? What is this thing? Dan. On Thu, June 24, 2010 4:34 pm, Joseph Salowey (jsalowey) wrote: > 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
