Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Dan Harkins wrote: > 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? Legacy password databases. > The only reason I can see to do PAP inside EAP-TTLS or EAP-FAST is > when using a token card or other OTP. For enterprises, this is a reasonable assumption. For ISPs, it's not. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Dan Harkins wrote: > Wrong, it "allows the user credentials to be exposed", depending on > the EAP method. Hmm... it requires that any user credentials in the tunnel be exposed. > I understand the difference (obviously a bit better than you do). And I > didn't ask you to list the differences. You said that the former "fails > the privacy requirements of any TLS-based EAP method." So I asked you a > simple question. Let me rephrase it for you in the hope you will answer > it: how do you propose to prevent this REQUIREMENT from not being met? The requirements are that the home system gets to choose the privacy requirements. If they choose to terminate TLS in the visited network, fine. If they choose to terminate the TLS method themselves, and then forward the user credentials elsewhere, fine. In that view, your question is irrelevant. The alternate view, and one I'm opposed to, is that a third-party chooses the privacy requirements for the home system. In that view, your question is highly relevant. Since it's not a view I hold, I cannot answer your question in any meaningful way. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Alan, On Thu, June 24, 2010 6:27 pm, Alan DeKok wrote: >> 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? > > The proposal to terminate TLS on the visited network *requires* that > the users credentials are exposed all the way down the proxy chain. Wrong, it "allows the user credentials to be exposed", depending on the EAP method. > The proposal to terminate TLS on the home network *permits* the home > system to do what it wants with the user credentials. > > If you can't see a difference between the two scenarios, then there is > nothing more to discuss. I understand the difference (obviously a bit better than you do). And I didn't ask you to list the differences. You said that the former "fails the privacy requirements of any TLS-based EAP method." So I asked you a simple question. Let me rephrase it for you in the hope you will answer it: how do you propose to prevent this REQUIREMENT from not being met? Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Dan Harkins wrote: > I disagree with disagreements that do not provide any justification > for disagreement. By the same token, your original opinion lacks justification, too. My opinion is based on my experiences. As you do not share those experiences, I understand why they would be new information. I don't understand why you would discount them completely as being unjustified. > 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. I think it's a false dichotomy to label trust as binary. A proxy may not be trusted with long-term secrets, because abusing those long-term secrets is easy. It may be trusted with short-term secrets, because those secrets are short-term, and abusing them is difficult. >> 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. By "in use", I meant "in practice". This should have been obvious from the example I gave, which you deleted. In case you didn't know, I've written freeware which does exactly that: terminate the TLS tunnel, and proxy the inner data. This capability has driven some of the experiences noted earlier. And I don't think hostapd has that capability, as it's a much more limited RADIUS server. > 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. Where is that used? Within an enterprise, or as part of a roaming consortium? Enterprises use it. They are terminating the TLS tunnel in the same administrative domain as the home AAA server. Which means no proxying. I don't know of any roaming consortium which uses that capability. > 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. I fail to see how using EAP in the inner tunnel is what "allows" the inner method to be terminated elsewhere. TTLS with PAP can be terminated elsewhere, too. > Notice how the tunnel method requirements document talks about "the > inner EAP method"? It's an EAP method, not just some credential exchange, That is not what the requirements document says. It refers to "inner authentication methods", and has no requirement that it be EAP. It *does* have requirements on the inner method if and when it is EAP. > and being an EAP method it can be sent to another device. Yes... as can any other inner authentication method. > How do you > propose that "the inner EAP method" terminate at the same place as the > tunnel? Pretty much the same way that people are doing it now. > Can you describe current deployments of tunnel methods that terminate > everything, EAP-TLS plus some client credential authentication, at the > home AAA server? Yes. Eduroam. Used by tens of thousands of people world-wide. > 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? The proposal to terminate TLS on the visited network *requires* that the users credentials are exposed all the way down the proxy chain. The proposal to terminate TLS on the home network *permits* the home system to do what it wants with the user credentials. If you can't see a difference between the two scenarios, then there is nothing more to discuss. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
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:dhark...@lounge.org] > Sent: Thursday, June 24, 2010 5:26 PM > To: Joseph Salowey (jsalowey) > Cc: Dan Harkins; Alan DeKok; emu@ietf.org; 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:dhark...@lounge.org] > >> Sent: Thursday, June 24, 2010 4:25 PM > >> To: Joseph Salowey (jsalowey) > >> Cc: Dan Harkins; Alan DeKok; emu@ietf.org; 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf > > Of > >> > Dan > >> >> Harkins > >> >> Sent: Thursday, June 24, 2010 3:07 PM > >> >> To: Alan DeKok > >> >> Cc: emu@ietf.org; 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 clien
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:dhark...@lounge.org] >> Sent: Thursday, June 24, 2010 4:25 PM >> To: Joseph Salowey (jsalowey) >> Cc: Dan Harkins; Alan DeKok; emu@ietf.org; 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf > Of >> > Dan >> >> Harkins >> >> Sent: Thursday, June 24, 2010 3:07 PM >> >> To: Alan DeKok >> >> Cc: emu@ietf.org; 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.
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
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:dhark...@lounge.org] > Sent: Thursday, June 24, 2010 4:25 PM > To: Joseph Salowey (jsalowey) > Cc: Dan Harkins; Alan DeKok; emu@ietf.org; 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > > Dan > >> Harkins > >> Sent: Thursday, June 24, 2010 3:07 PM > >> To: Alan DeKok > >> Cc: emu@ietf.org; 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&#
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Dan >> Harkins >> Sent: Thursday, June 24, 2010 3:07 PM >> To: Alan DeKok >> Cc: emu@ietf.org; 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 b
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Dan >> Harkins >> Sent: Thursday, June 24, 2010 3:07 PM >> To: Alan DeKok >> Cc: emu@ietf.org; 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 devic
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Dan > Harkins > Sent: Thursday, June 24, 2010 3:07 PM > To: Alan DeKok > Cc: emu@ietf.org; 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.
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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
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. > If someone's doing PAP they're using a token card or some type of > OTP. 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. > 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. > 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. > 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. > If the client's credential needs more protection than the MSK > then why are we bothering with the tunnel method work? If you have a > pre-shared key, code, phrase, or word use EAP-pwd; if you have a > certified public key use EAP-TLS. That protects the client's credential > and regardless of where it's terminated the MSK will be seen by > intermediate proxies but so what. I agree with Sam on this point. I'm also unsure about the benefit of using a TLS-based method without using supplicant to home AAA TLS. Existing WiFi networks *already* use TLS for the web pages obtained over HTTPS. They then use WISPr to post the passwords. This is semantically identical to the proposal to terminate EAP-TLS locally, and proxy the inner tunnel data. The reason EAP channel bindings are being proposed is that many of the people who've deployed "local TLS + password" login methods see it as insufficient. They pretty much have the solution proposed by Glen, and they want something more. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Sam, 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. If someone has a long-term password they're doing EAP-MSCHAPv2. If someone's doing PAP they're using a token card or some type of OTP. 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? I suggest you refrain from doing business with the company operating it then because you have bigger issues. Just out of curiosity, though, how do you propose to prevent a proxy from seeing an MS-CHAPv2 exchange or an OTP fly by? 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. Do you want to prohibit an "inner method" from terminating on a different entity than the "outer (tunnel) method"? If the client's credential needs more protection than the MSK then why are we bothering with the tunnel method work? If you have a pre-shared key, code, phrase, or word use EAP-pwd; if you have a certified public key use EAP-TLS. That protects the client's credential and regardless of where it's terminated the MSK will be seen by intermediate proxies but so what. Dan. On Thu, June 24, 2010 11:56 am, Sam Hartman wrote: >> "Dan" == Dan Harkins writes: > > Dan> Hi Alan, > > Dan> On Thu, June 24, 2010 5:20 am, Alan DeKok wrote: > >> Glen Zorn wrote: >>> Alan DeKok [mailto:al...@deployingradius.com] writes: > The requirement to keep authentication credentials private, > which is one of the reasons for choosing a TLS-based method in > the first place. > >>> > >>> Are you confused? We're talking about being able to > >>> authenticate the visited network, not tunnel method > >>> requirements... > >> > >> Your proposal authenticates the visited network, at the cost of > >> exposing the users authentication credentials to the visited > >> network, and to everyone else in the proxy chain. This fails the > >> privacy requirements of any TLS-based EAP method, and has nothing > >> at all to do with the tunnel method requirements. > > Dan> I may be missing something but the key shared by the client > Dan> and the NAS is going to be known by the proxies in that chain > Dan> so what sort of problem is being solved by applying these > Dan> privacy requirements to proxies? > The MSK is a relatively short-term key. The credentials that proxies > may be able to attack are long-term credentials. > So, I'm with Alan: the long-term credentials are more important than the > Dan> MSK. > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
> "Dan" == Dan Harkins writes: Dan> Hi Alan, Dan> On Thu, June 24, 2010 5:20 am, Alan DeKok wrote: >> Glen Zorn wrote: >> Alan DeKok [mailto:al...@deployingradius.com] writes: The requirement to keep authentication credentials private, which is one of the reasons for choosing a TLS-based method in the first place. >>> >>> Are you confused? We're talking about being able to >>> authenticate the visited network, not tunnel method >>> requirements... >> >> Your proposal authenticates the visited network, at the cost of >> exposing the users authentication credentials to the visited >> network, and to everyone else in the proxy chain. This fails the >> privacy requirements of any TLS-based EAP method, and has nothing >> at all to do with the tunnel method requirements. Dan> I may be missing something but the key shared by the client Dan> and the NAS is going to be known by the proxies in that chain Dan> so what sort of problem is being solved by applying these Dan> privacy requirements to proxies? The MSK is a relatively short-term key. The credentials that proxies may be able to attack are long-term credentials. So, I'm with Alan: the long-term credentials are more important than the Dan> MSK. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Hi Alan, On Thu, June 24, 2010 5:20 am, Alan DeKok wrote: > Glen Zorn wrote: >> Alan DeKok [mailto:al...@deployingradius.com] writes: >>> The requirement to keep authentication credentials private, which is >>> one of the reasons for choosing a TLS-based method in the first place. >> >> Are you confused? We're talking about being able to authenticate the >> visited network, not tunnel method requirements... > > Your proposal authenticates the visited network, at the cost of > exposing the users authentication credentials to the visited network, > and to everyone else in the proxy chain. This fails the privacy > requirements of any TLS-based EAP method, and has nothing at all to do > with the tunnel method requirements. I may be missing something but the key shared by the client and the NAS is going to be known by the proxies in that chain so what sort of problem is being solved by applying these privacy requirements to proxies? There are man-in-the-middle attacks and dictionary attacks possible by an attacker between the client and the NAS and these tunneled EAP methods address that. But if you think that it's a problem for a proxy between the TTLS server and the AAA server to see the client's credentials then don't you think it's a (bigger) problem that this proxy will have access to the client's key? Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
> "Glen" == Glen Zorn writes: Glen> If certificate-based TLS authentication is used & the TTLS Glen> server is located in the visited network (something that the Glen> client can check by matching the identity advertised with a Glen> name in the cert), the task is accomplished (in that the Glen> problem becomes one of policy, provisioning and implementation Glen> rather than protocol design or standardization). Glen, thanks for explaining this. I now believe I understand what you're proposing. Like Alan, I'm concerned about the security and privacy implications of have the TTLS server be in the visited network in a different organization. However we can do something similar. We could have the home AAA server use a different EAP server or at least different TLS certificate for the corporate network than for other networks. From the standpoint of the client I think this is very similar to what you describe. It has some advantages, including that we don't need to ask visited networks to change their configuration or deploy TTLS servers. I agree that works for the case I proposed. However I do not prefer it as a solution. At this point , I think we understand each other's positions and have clear disagreement. We are not going to be able to change each other's minds. So, the WG will have to come to consensus on whether channel binding has value. For the record, here are the reasons I prefer channel binding to using different certificates to distinguish properties of the network. Channel binding scales better on dimensions that I care about. For each set of attributes that a client wants to distinguish I need a separate certificate with the TLS approach. With channel binding, the client simply needs to give these attributes to the EAP server. Significantly increasing the number of certificates is likely to complicate management of the client and of the PKI within the organization. If an external CA is used, this may involve a significant cost. Using TLS certificates tends to require that all clients want to distinguish the same attributes of the network. With channel binding, two clients can send a different set of attributes for validation against the channel binding information. The certificate approach seems like it will be very complicated especially when an organization wishes to change the set of attributes that clients wish to distinguish. I think channel binding does less damage to the conceptual EAP model than this TLS approach. Today in EAP, the peer authenticates to the issuer of its credentials; given a credential, a peer typically knows who the other party will be. Trust management between the peer and EAP server is relatively simple in this model. However, if TLS certificates represent networks rather than credential issuers, then the conceptual parties in the security model change. I think that complicates trust; the privacy issues Alan brings up are the most obvious example. In contrast, I at least believe that channel binding fits within the existing EAP model. Certainly, we've done a lot of analysis including the EAP keying framework and the AAA key management requirements assuming such a facility and this analysis does not appear to have shown a disconnect between the EAP model and channel binding. I'll note that channel binding appears very easy to add to TTLS. However, there is one case where the of multiple TLS certificates may provide a significant benefit over traditional channel binding. If there is an entity trusted by the client that is significantly closer to the NAS than the home EAP server, then having a TTLS tunnel to that entity may provide a point that is in a better position to make statements about the NAS. I'll note that this approach has significant power when combined with channel binding. However it seems like there is a lot of complexity involved and issues to work through. It seems like having trust relationships with all these entities in the network will require a fairly complex PKI or complex client management. It seems like this approach is getting away from the AAA model, which at least as I conceptualize it has a major goal of limiting the trust management of the client. Figuring out when to route an EAP conversation through such an endpoint seems kind of tricky; what set of clients is it done for? Do clients request such routing? If so, how? If not, how is the cross-organizational configuration managed? Still, I think this use case is quite interesting and is something we should examine. --Sam ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen Zorn wrote: > Alan DeKok [mailto:al...@deployingradius.com] writes: >> The requirement to keep authentication credentials private, which is >> one of the reasons for choosing a TLS-based method in the first place. > > Are you confused? We're talking about being able to authenticate the > visited network, not tunnel method requirements... Your proposal authenticates the visited network, at the cost of exposing the users authentication credentials to the visited network, and to everyone else in the proxy chain. This fails the privacy requirements of any TLS-based EAP method, and has nothing at all to do with the tunnel method requirements. >> Is there a document describing that? Will implementations be >> interoperable without a document? What security and privacy issues are >> there with doing that? > > RFC 5281. i.e. EAP-TTLS, which is informational, not standards track. And it has little or no discussion on the dual authentication which would be necessary for your proposal to work. >> Roaming was just one example. Even with roaming, there are multiple >> roaming consortia, for multiple purposes. Standardizing a >> cross-consortia method for channel bindings would appear to be useful to >> the wider Internet Community, and well within the scope of the IETF. > > How does this affect the fact that the stated goal of making sure that the > network to which the client is attached is the one that was advertised? Channel bindings are proposed to solve that, and other issues. The proposal is to do this without exposing authentication credentials to everyone. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Alan DeKok [mailto:al...@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto:al...@deployingradius.com] writes: > >> This proxying violates the privacy requirements. > > > > What privacy requirements are those? > > The requirement to keep authentication credentials private, which is > one of the reasons for choosing a TLS-based method in the first place. Are you confused? We're talking about being able to authenticate the visited network, not tunnel method requirements... > > >> Unless I'm missing something, that would require standards action, > as > >> there is no document describing TLS inside of TTLS. > > > > EAP-TTLS provides for the transport of EAP inside the TLS tunnel. > > Is there a document describing that? Will implementations be > interoperable without a document? What security and privacy issues are > there with doing that? RFC 5281. > > >> There is no > >> document describing how the client could perform the certificate > checks > >> against the local network information, so that would require > standards > >> action, too. > > > > Why? I thought that we were talking about commercial entities here: > > certainly roaming consortia can specify how they want to take care of > > internal matters... > > Roaming was just one example. Even with roaming, there are multiple > roaming consortia, for multiple purposes. Standardizing a > cross-consortia method for channel bindings would appear to be useful to > the wider Internet Community, and well within the scope of the IETF. How does this affect the fact that the stated goal of making sure that the network to which the client is attached is the one that was advertised? > > Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen Zorn wrote: > Alan DeKok [mailto:al...@deployingradius.com] writes: >> This proxying violates the privacy requirements. > > What privacy requirements are those? The requirement to keep authentication credentials private, which is one of the reasons for choosing a TLS-based method in the first place. >> Unless I'm missing something, that would require standards action, as >> there is no document describing TLS inside of TTLS. > > EAP-TTLS provides for the transport of EAP inside the TLS tunnel. Is there a document describing that? Will implementations be interoperable without a document? What security and privacy issues are there with doing that? >> There is no >> document describing how the client could perform the certificate checks >> against the local network information, so that would require standards >> action, too. > > Why? I thought that we were talking about commercial entities here: > certainly roaming consortia can specify how they want to take care of > internal matters... Roaming was just one example. Even with roaming, there are multiple roaming consortia, for multiple purposes. Standardizing a cross-consortia method for channel bindings would appear to be useful to the wider Internet Community, and well within the scope of the IETF. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Alan DeKok [mailto:al...@deployingradius.com] writes: > Glen Zorn wrote: > > If certificate-based TLS authentication is used & the TTLS server is > located > > in the visited network (something that the client can check by > matching the > > identity advertised with a name in the cert), the task is accomplished > (in > > that the problem becomes one of policy, provisioning and > implementation > > rather than protocol design or standardization). > > My understanding was that the TLS tunnel was used for at least two > purposes. One was to perform TLS server validation, as you suggest > above. Another was to provide privacy for authentication credentials. > > The proposal above satisfies the first purpose, but satisfies the > second only when the TTLS & home AAA server are co-located, or in the > same management domain. > > For roaming, the TTLS server is not in the same management domain as > the home AAA server. The proposal above would require that the TTLS > server take the authentication credentials from inside of the TLS > tunnel, and proxy them over normal RADIUS, without the protection of a > TLS tunnel > > This proxying violates the privacy requirements. What privacy requirements are those? > > The only way I could see this method working is if the data inside of > the TLS tunnel was another TLS session. The client could verify that > the outer session matched the local network, and that the inner session > matched the home network. > > Unless I'm missing something, that would require standards action, as > there is no document describing TLS inside of TTLS. EAP-TTLS provides for the transport of EAP inside the TLS tunnel. > There is no > document describing how the client could perform the certificate checks > against the local network information, so that would require standards > action, too. Why? I thought that we were talking about commercial entities here: certainly roaming consortia can specify how they want to take care of internal matters... > > And I'm not sure why this applies only to TTLS. I see this as > applying equally well (or poorly) any other TLS-based EAP method. > > Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen Zorn wrote: > If certificate-based TLS authentication is used & the TTLS server is located > in the visited network (something that the client can check by matching the > identity advertised with a name in the cert), the task is accomplished (in > that the problem becomes one of policy, provisioning and implementation > rather than protocol design or standardization). My understanding was that the TLS tunnel was used for at least two purposes. One was to perform TLS server validation, as you suggest above. Another was to provide privacy for authentication credentials. The proposal above satisfies the first purpose, but satisfies the second only when the TTLS & home AAA server are co-located, or in the same management domain. For roaming, the TTLS server is not in the same management domain as the home AAA server. The proposal above would require that the TTLS server take the authentication credentials from inside of the TLS tunnel, and proxy them over normal RADIUS, without the protection of a TLS tunnel This proxying violates the privacy requirements. The only way I could see this method working is if the data inside of the TLS tunnel was another TLS session. The client could verify that the outer session matched the local network, and that the inner session matched the home network. Unless I'm missing something, that would require standards action, as there is no document describing TLS inside of TTLS. There is no document describing how the client could perform the certificate checks against the local network information, so that would require standards action, too. And I'm not sure why this applies only to TTLS. I see this as applying equally well (or poorly) any other TLS-based EAP method. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Sam Hartman [mailto:hartmans-i...@mit.edu] writes: > > "Glen" == Glen Zorn writes: > > > Glen> Or we could use the more direct & much simpler approach of > Glen> allowing the client to authenticate the network to which it is > Glen> attached & use that data to decide by itself. This can be > Glen> done today using EAP-TTLS. > > How? > I'd appreciate an answer in approximately similar level of detail as I > have given you the answer on the channel binding approach. I was hoping that someone with a higher level of expertise WRT eap-ttls than mine would jump in here (Steve Hannah, for example) but I'll do my best. Section 5 of RFC 5281 says: 5. Architectural Model The network architectural model for EAP-TTLS usage and the type of security it provides is shown below. +--+ +--+ +--+ +--+ | | | | | | | | | client |<>| access |<>| TTLS AAA |<>| AAA/H | | | | point | | server | | server | | | | | | | | | +--+ +--+ +--+ +--+ < secure password authentication tunnel ---> < secure data tunnel > The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TTLS server and AAA/H server might be a single entity; the access point and TTLS server might be a single entity; or, indeed, the functions of the access point, TTLS server and AAA/H server might be combined into a single physical device. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. Note also that one or more AAA proxy servers might be deployed between access point and TTLS server, or between TTLS server and AAA/H server. Such proxies typically perform aggregation or are required for realm-based message routing. However, such servers play no direct role in EAP-TTLS and are therefore not shown. If certificate-based TLS authentication is used & the TTLS server is located in the visited network (something that the client can check by matching the identity advertised with a name in the cert), the task is accomplished (in that the problem becomes one of policy, provisioning and implementation rather than protocol design or standardization). ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen Zorn wrote: > Note that transitive trust issues are irrelevant if EAP-TTLS is used. I agree with Sam here. I'd like to see more explanation behind this assertion. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
> "Glen" == Glen Zorn writes: Glen> Or we could use the more direct & much simpler approach of Glen> allowing the client to authenticate the network to which it is Glen> attached & use that data to decide by itself. This can be Glen> done today using EAP-TTLS. How? I'd appreciate an answer in approximately similar level of detail as I have given you the answer on the channel binding approach. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Sam Hartman [mailto:hartm...@mit.edu] writes: > > "Glen" == Glen Zorn writes: > Hi. I have read the later messages on this thread, but it sounded like > you and Alan were talking past each other a bit, so I want to come back > to where I think the disagreement is introduced. > > > Glen> Sam Hartman [mailto://hartmans-i...@mit.edu] writes: > > >> Consider a corporation that has an internal network and that also > >> has agreements with WIFI hotspots to provide its employees > >> connectivity. Policy requires that people use a different set of > >> firewall rules and VPN configuration when connecting at the WIFI > >> hotspots than when connecting to the home network. Typically > >> clients determine which network is in use by the SSID. They use > >> the same EAP credentials in both cases. > >> > >> You can imagine that the corporation would know the identities of > >> its own access points. In particular, a combination of > >> configuration on the AAA servers and at the boundary firewall > >> could mean that the AAA servers know whether a given request for > >> access is coming from the corporate network or a WIFI hotspot. > >> Today, however, the corporate AAA infrastructure does not know > >> what the client thinks it is connecting to. If the client > >> disclosed the SSID it sees then the corporation would be in a > >> position to enforce the security policy. > >> > >> Glen agreed that channel binding could address this. > > Glen> Indeed it could, but all you really seem to be asking for is a > Glen> way for the corporation to be able to control the > Glen> configuration of the client. As you point out, it is > Glen> reasonable to expect that the corporation knows the identity > Glen> of its own access points; why does it matter what the client > Glen> _thinks_ (for lack of a better word) that it is attached to? > Glen> I cannot see any purpose for the client sending the SSID of > Glen> the network to which it attached. In fact, it seems that all > Glen> that is necessary is the ability to remotely modify the > Glen> configuration of a client; why is the job of EAP, again? > > > > The client has two different policies both of which have been configured > by the corporate infrastructure. > > The first policy is a policy to be used when connected directly to the > corporate network. The second policy is a policy to be used when > connected to more open networks. > > The client knows both policies. The client needs to choose which one to > use. > The client needs a procedure for connecting to the network such that on > success: > > 1) The client uses the corporate policy on the corporate network and the > other policy on other networks > 2) The client has an authenticated EAP and 802.11I association; the EAP > association to the EAP server and the 802.11I association to the access > point > 3) No attacker can convince the client to use the corporate policy when > connecting to other networks or the other policy when connecting to the > corporate network without the cooperation of the corporate AAA > infrastructure > > So, somehow the client needs to discover which policy to use. We could > use an insecure discovery mechanism and validate the results of that > discovery with a secure protocol later. Alternatively we could use a > secure discovery mechanism and bind the results of that mechanism to the > rest of our protocol. As far as I can tell binding secure discovery to > the later stages of the protocol is exactly as hard as validating > insecure discovery, so I'll design a solution for insecure discovery. I > propose that the client discover which policy to use by looking at the > SSIDs advertised by the APs. I understand SSIDs may not be unique; as a > consequence our client will end up being unable to connect to a > non-corporate network that happens to have chosen the same SSID as the > corporate network. If you design a better discovery mechanism we can > remove this defect; in practice if the corporate SSID is well-chosen > this is not a significant problem. > > So, based on the SSID, we have discovered what policy we will try to > use. Since our discovery approach is entirely insecure, an attacker can > give us the wrong policy to try. If our overall approach is secure, > then we must fail at a later step if that happens. > > In this system, we've posited that the corporate AAA infrastructure > knows whether a given AP is corporate or other. So, we want to take > advantage of that information. We need to change the corporate AAA > behavior to do that as it doesn't provide that service today. We could: > > 1) We can tell the corporate AAA infrastructure what policy we plan to > use and have it validate that decision. > 2) The corporate AAA infrastructure can tell us what policy we should > be using. Or we could use the more direct & much simpler a
