Who said anything about making them mandatory? I just said SHOULD. Yes, Joe pointed out that the current MUST NOT language does not necessarily bar anyone from supporting them, but how do you then jump to the conclusion that saying they SHOULD be supported makes them mandatory?
RFC 2119 says of SHOULD: "there may exist valid reasons in particular circumstances [like the points I have been making] to ignore a particular item [like the admonitions to do server-side authentication], but the full implications [potential loss of privacy] must be understood and carefully weighed before choosing a different course." It does not indicate an absolute or mandatory requirement. Dan. On Thu, March 4, 2010 1:30 pm, Hoeper Katrin-QWKN37 wrote: > 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
