MUST NOT be mandatory in combination with SHOULD be supported...sounds a little bit odd to me!
We have good reasons to have the MUST NOT be mandatory. Again, support is not excluded by this statement. Katrin > -----Original Message----- > From: Dan Harkins [mailto:[email protected]] > Sent: Thursday, March 04, 2010 4:30 PM > To: Hoeper Katrin-QWKN37 > Cc: Joseph Salowey; Dan Harkins; [email protected]; Yaron Sheffer > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > 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
