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 <[email protected]> writes: > > Dan> Hi Alan, > > Dan> On Thu, June 24, 2010 5:20 am, Alan DeKok wrote: > >> Glen Zorn wrote: >>> Alan DeKok [mailto:[email protected]] 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
