I am absolutely against adding a SHOULD requirement for anonymous tunnels. Dan you made your point that there are use cases where servers don't have a certificate and don't use secret key credentials supported by TLS.
To make anonymous tunnels *mandatory* to support these corner cases seems a bit far fetched considering that it would require a whole list of additional security requirements on the inner method. As Joe pointed out the current draft does not prohibit anonymous tunnels, it just doesn't make them mandatory. I agree, that an extension to the base protocol is a much better place to discuss these use cases and the required additional limitations on the inner methods. Katrin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, March 04, 2010 1:10 PM > To: Dan Harkins > Cc: [email protected]; Yaron Sheffer > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > I don't think it's appropriate to add a SHOULD for implementing > anonymous cipher suites in this document. > > It is true that there is a MUST requirement for extensibility, but I > don't think we want to define the extensions in the base specification. > I don't think the current text limits what can be done in extensions. > > Joe > > > -----Original Message----- > > From: Dan Harkins [mailto:[email protected]] > > Sent: Thursday, March 04, 2010 8:50 AM > > To: Joseph Salowey (jsalowey) > > Cc: Yaron Sheffer; [email protected] > > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > > > Hi Joe, > > > > Section 3.8 has a MUST for "extensibility" which is explained as: > > > > "One example of a application for extensibility is credential > > provisioning. When a peer has authenticated with EAP, this is a > > convenient time to distribute credentials to that peer that may > be > > used for later authentication exchanges." > > > > Now I believe EAP-FAST does this sort of thing for it's PAC > provisioning > > but it does anonymous TLS then EAP-MSCHAPv2 which has obvious > problems. > > So the need to do this sort of thing exists. > > > > I know that one can do server-side authentication with some > previously > > installed certificate (and I know EAP-FAST has this as an option too) > but > > _in practice_ that doesn't work so well which is why the most popular > > desktop and laptop operating system has a "do not verify server cert" > > check box on its EAP-TLS configuration GUI. > > > > As I mentioned earlier security is about risk management and if you > > try to tell some guy deploying product that no he can't do what he > wants > > to do because the authors of the IETF standard decided that it wasn't > > in his best interests he will find ways around those authors, like > instead > > of installing a trusted cert he'll check the box to not verify the > server > > cert that the authors said he has to use if he wants to use this > product. > > It would be much better to give him a tool that serves his legitimate > > needs and is easy for him to deploy and still maintains security > (albeit > > with a potential loss of privacy). > > > > Would it be possible to add a reference in 4.2.1.1.3 that one SHOULD > > optionally implement an anonymous cipher suite? > > > > Dan. > > > > On Thu, March 4, 2010 7:11 am, Joseph Salowey (jsalowey) wrote: > > >> Joe, what Dan is proposing is a reasonable way to use a one-time > > > password > > >> for the initial provisioning of a trust anchor. Initial > provisioning > > > is > > >> important for many types of deployments. Does the document allow an > > >> alternative secure way to do that? > > >> > > > [Joe] Initial provisioning is not currently in the scope of the > document > > > for the base method. I agree that using anonymous cipher suites in > the > > > way Dan proposes can be used in a provisioning mechanism, however > there > > > are other ways provisioning can be achieved with or without the use > of > > > EAP. > > > > > >> Dan, I suspect that for this specific use case (one time use, no > need > > > for > > >> confidentiality), resistance against dictionary attack is not very > > >> important. So EAP-GPSK inside the tunnel will do just as well. > > >> > > >> Thanks, > > >> Yaron > > >> > > >> > Date: Wed, 3 Mar 2010 20:05:09 -0800 > > >> > From: "Joseph Salowey (jsalowey)" <[email protected]> > > >> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > >> > To: "Dan Harkins" <[email protected]>, "Hoeper Katrin-QWKN37" > > >> > <[email protected]> > > >> > Cc: [email protected] > > >> > Message-ID: > > >> > <ac1cfd94f59a264488dc2bec3e890de509bd3...@xmb-sjc- > > >> > 225.amer.cisco.com> > > >> > Content-Type: text/plain; charset="us-ascii" > > >> > > > >> > Hi Dan, > > >> > > > >> > The document currently states anonymous cipher suites MUST NOT be > > >> > mandatory to implement for the tunnel method. I think the is the > > >> > appropriate stance for the document to take for the base tunnel > > > method. > > >> > I also do not think this prevents a follow-on specification > defining > > >> > how > > >> > to use anonymous tunnel securely. > > >> > > > >> > Cheers, > > >> > > > >> > Joe > > >> > > > >> > > >> _______________________________________________ > > >> 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 _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
