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
