This is way off topic for the channel binding discussion, and has been discussed numerous times before. Instead of taking the list deeper into this discussion I suggest we take this off line.
> -----Original Message----- > From: Dan Harkins [mailto:[email protected]] > Sent: Thursday, June 24, 2010 5:26 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 > > > 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
