Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
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:dhark...@lounge.org] > Sent: Thursday, March 04, 2010 4:30 PM > To: Hoeper Katrin-QWKN37 > Cc: Joseph Salowey; Dan Harkins; emu@ietf.org; 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > >> Joseph Salowey (jsalowey) > >> Sent: Thursday, March 04, 2010 1:10 PM > >> To: Dan Harkins > >> Cc: emu@ietf.org; 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:dhark...@lounge.org] > >> > Sent: Thursday, March 04, 2010 8:50 AM > >> > To: Joseph Salowey (jsalowey) > >> > Cc: Yaron Sheffer; emu@ietf.org > >> > 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 > >> >
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >> Joseph Salowey (jsalowey) >> Sent: Thursday, March 04, 2010 1:10 PM >> To: Dan Harkins >> Cc: emu@ietf.org; 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:dhark...@lounge.org] >> > Sent: Thursday, March 04, 2010 8:50 AM >> > To: Joseph Salowey (jsalowey) >> > Cc: Yaron Sheffer; emu@ietf.org >> > 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 Sal
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Thursday, March 04, 2010 1:10 PM > To: Dan Harkins > Cc: emu@ietf.org; 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:dhark...@lounge.org] > > Sent: Thursday, March 04, 2010 8:50 AM > > To: Joseph Salowey (jsalowey) > > Cc: Yaron Sheffer; emu@ietf.org > > 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 > > >>
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:dhark...@lounge.org] > Sent: Thursday, March 04, 2010 8:50 AM > To: Joseph Salowey (jsalowey) > Cc: Yaron Sheffer; emu@ietf.org > 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)" > >> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > To: "Dan Harkins" , "Hoeper Katrin-QWKN37" > >> > > >> > Cc: emu@ietf.org > >> > Message-ID: > >> > >> > 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 > >> Emu@ietf.org > >> https://www.ietf.org/mailman/listinfo/emu > > ___ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
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)" >> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> > To: "Dan Harkins" , "Hoeper Katrin-QWKN37" >> > >> > Cc: emu@ietf.org >> > Message-ID: >> >> > 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 >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Joe, Yes, I am OK with the text. Thanks, Yaron > -Original Message- > From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] > Sent: Thursday, March 04, 2010 17:12 > To: Yaron Sheffer; Alan DeKok > Cc: emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > Hi Yaron, > > The existing text is just about restricting the mandatory to implement > cipher suites. Are you OK with the text? > > Thanks, > > Joe > > > -Original Message- > > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > > Yaron Sheffer > > Sent: Wednesday, March 03, 2010 11:05 PM > > To: Alan DeKok > > Cc: emu@ietf.org > > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > Hi Alan, > > > > Initial provisioning by shipping the device with the trust anchor > pre- > > installed is fine, if you're Verizon. But in many cases you don't > control > > the device, and don't have a trusted path through which to transport > the > > CA cert (I am thinking enterprise CA here, not a public CA). The > > combination of anonymous tunnel plus mutual auth with a one-time > password > > allows you to do that. > > > > But I'm OK with not making this option mandatory, since there are > > important use cases that don't need it. > > > > Thanks, > > Yaron > > > > > -----Original Message- > > > From: Alan DeKok [mailto:al...@deployingradius.com] > > > Sent: Thursday, March 04, 2010 8:47 > > > To: Yaron Sheffer > > > Cc: emu@ietf.org > > > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > > > Yaron Sheffer 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? > > > > > > TLS-based methods can leverage server certificates. This is > already > > > done in other areas (WiMAX, etc.) > > > > > > i.e. ship a device with a known CA, and on first provisioning, > TLS > > > checks the server certificate, and the user validates that the name > of > > > the server is what was expected. > > > > > > Since the document doesn't forbid anonymous methods, the only > issue > > > here is whether or not the document should make them mandatory to > > > implement. I agree with Joe, in that they shouldn't be mandatory. > > > > > > Alan DeKok. > > > > > > Scanned by Check Point Total Security Gateway. > > ___ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > Scanned by Check Point Total Security Gateway. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Yaron, The existing text is just about restricting the mandatory to implement cipher suites. Are you OK with the text? Thanks, Joe > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Wednesday, March 03, 2010 11:05 PM > To: Alan DeKok > Cc: emu@ietf.org > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > Hi Alan, > > Initial provisioning by shipping the device with the trust anchor pre- > installed is fine, if you're Verizon. But in many cases you don't control > the device, and don't have a trusted path through which to transport the > CA cert (I am thinking enterprise CA here, not a public CA). The > combination of anonymous tunnel plus mutual auth with a one-time password > allows you to do that. > > But I'm OK with not making this option mandatory, since there are > important use cases that don't need it. > > Thanks, > Yaron > > > -Original Message- > > From: Alan DeKok [mailto:al...@deployingradius.com] > > Sent: Thursday, March 04, 2010 8:47 > > To: Yaron Sheffer > > Cc: emu@ietf.org > > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > Yaron Sheffer 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? > > > > TLS-based methods can leverage server certificates. This is already > > done in other areas (WiMAX, etc.) > > > > i.e. ship a device with a known CA, and on first provisioning, TLS > > checks the server certificate, and the user validates that the name of > > the server is what was expected. > > > > Since the document doesn't forbid anonymous methods, the only issue > > here is whether or not the document should make them mandatory to > > implement. I agree with Joe, in that they shouldn't be mandatory. > > > > Alan DeKok. > > > > Scanned by Check Point Total Security Gateway. > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 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)" > > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > To: "Dan Harkins" ,"Hoeper Katrin-QWKN37" > > > > Cc: emu@ietf.org > > Message-ID: > > > 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 > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Yaron Sheffer wrote: > Hi Alan, > > Initial provisioning by shipping the device with the trust anchor > pre-installed is fine, if you're Verizon. But in many cases you don't control > the device, and don't have a trusted path through which to transport the CA > cert (I am thinking enterprise CA here, not a public CA). Enterprises usually have areas which are physically secure, and that can be used to bootstrap the system. Anonymous provisioning is more useful for ISPs and telcos, who need to provision users in random places. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Alan, Initial provisioning by shipping the device with the trust anchor pre-installed is fine, if you're Verizon. But in many cases you don't control the device, and don't have a trusted path through which to transport the CA cert (I am thinking enterprise CA here, not a public CA). The combination of anonymous tunnel plus mutual auth with a one-time password allows you to do that. But I'm OK with not making this option mandatory, since there are important use cases that don't need it. Thanks, Yaron > -Original Message- > From: Alan DeKok [mailto:al...@deployingradius.com] > Sent: Thursday, March 04, 2010 8:47 > To: Yaron Sheffer > Cc: emu@ietf.org > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > Yaron Sheffer 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? > > TLS-based methods can leverage server certificates. This is already > done in other areas (WiMAX, etc.) > > i.e. ship a device with a known CA, and on first provisioning, TLS > checks the server certificate, and the user validates that the name of > the server is what was expected. > > Since the document doesn't forbid anonymous methods, the only issue > here is whether or not the document should make them mandatory to > implement. I agree with Joe, in that they shouldn't be mandatory. > > Alan DeKok. > > Scanned by Check Point Total Security Gateway. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Yaron Sheffer 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? TLS-based methods can leverage server certificates. This is already done in other areas (WiMAX, etc.) i.e. ship a device with a known CA, and on first provisioning, TLS checks the server certificate, and the user validates that the name of the server is what was expected. Since the document doesn't forbid anonymous methods, the only issue here is whether or not the document should make them mandatory to implement. I agree with Joe, in that they shouldn't be mandatory. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
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? 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)" > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > To: "Dan Harkins" , "Hoeper Katrin-QWKN37" > > Cc: emu@ietf.org > Message-ID: >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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
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 > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Dan > Harkins > Sent: Wednesday, March 03, 2010 3:30 PM > To: Hoeper Katrin-QWKN37 > Cc: emu@ietf.org > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hi Katrin, > > Yes, EAP-pwd uses the password for mutual authentication. If the > server doesn't know the password the exchange will fail. The key > differentiator (from, say, EAP-GPSK) is that it uses a zero knowledge > proof and is resistant to off-line dictionary attack. > > Dan. > > On Wed, March 3, 2010 2:33 pm, Hoeper Katrin-QWKN37 wrote: > > Sorry Dan, > > > > Is EAP-pwd using the password for mutual authentication? > > > >> -Original Message- > >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > >> Hoeper Katrin-QWKN37 > >> Sent: Wednesday, March 03, 2010 4:28 PM > >> To: Dan Harkins > >> Cc: emu@ietf.org > >> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > >> How does that authenticate the server if a user enters a password? > >> > >> If the server says, yes that was the right password? > >> > >> > >> > >> > -Original Message----- > >> > From: Dan Harkins [mailto:dhark...@lounge.org] > >> > Sent: Wednesday, March 03, 2010 4:14 PM > >> > To: Hoeper Katrin-QWKN37 > >> > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > >> > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > > >> > > >> > Since they both use the same low-entropy password to perform their > >> > mutual authentication it is not, strictly speaking, just the peer's > >> > credential. > >> > > >> > Dan. > >> > > >> > On Wed, March 3, 2010 1:45 pm, Hoeper Katrin-QWKN37 wrote: > >> > > > >> > > See inline. > >> > >> -Original Message- > >> > >> From: Dan Harkins [mailto:dhark...@lounge.org] > >> > >> Sent: Wednesday, March 03, 2010 3:39 PM > >> > >> To: Hoeper Katrin-QWKN37 > >> > >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > >> > >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > >> > >> > >> > >> > >> Hi Katrin, > >> > >> > >> > >> On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: > >> > >> > Dan, > >> > >> > > >> > >> > OK, I understand that the tunnel provides all these other > > feats. > >> > >> > > >> > >> > But why can't the server authenticate during the tunnel > > protocol? > >> I > >> > >> > still don't understand the use case for mutually anonymous > >> tunnels. > >> > >> > >> > >> Because it doesn't have the right credential. > >> > >> > >> > >> > If the server has a certificate why can't it send it to the > > peer > >> > > before > >> > >> > or during the tunnel establishment? > >> > >> > >> > >> If the server has a certificate then sending it to the peer > >> > >> would not really solve any problem. The peer would still need to > >> > >> have a reason to trust it and we're back to the problem of > > putting > >> > >> a trusted certificate in some certificate store. A global PKI to > >> > >> solve all of our certificate issues still has not materialized. > >> > >> > >> > >> > If the peer and server share a secret, than this could be used > > to > >> > >> > establish the tunnel. > >> > >> > >> > >> If the peer and server share a secret they could use one of the > >> PSK > >> > >> ciphersuites for TLS but those are susceptible to a dictionary > >> attack > >> > >> and are therefore inappropriate. > >> > >> >
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Katrin, Yes, EAP-pwd uses the password for mutual authentication. If the server doesn't know the password the exchange will fail. The key differentiator (from, say, EAP-GPSK) is that it uses a zero knowledge proof and is resistant to off-line dictionary attack. Dan. On Wed, March 3, 2010 2:33 pm, Hoeper Katrin-QWKN37 wrote: > Sorry Dan, > > Is EAP-pwd using the password for mutual authentication? > >> -Original Message- >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >> Hoeper Katrin-QWKN37 >> Sent: Wednesday, March 03, 2010 4:28 PM >> To: Dan Harkins >> Cc: emu@ietf.org >> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> >> How does that authenticate the server if a user enters a password? >> >> If the server says, yes that was the right password? >> >> >> >> > -Original Message- >> > From: Dan Harkins [mailto:dhark...@lounge.org] >> > Sent: Wednesday, March 03, 2010 4:14 PM >> > To: Hoeper Katrin-QWKN37 >> > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org >> > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> > >> > >> > Since they both use the same low-entropy password to perform their >> > mutual authentication it is not, strictly speaking, just the peer's >> > credential. >> > >> > Dan. >> > >> > On Wed, March 3, 2010 1:45 pm, Hoeper Katrin-QWKN37 wrote: >> > > >> > > See inline. >> > >> -----Original Message- >> > >> From: Dan Harkins [mailto:dhark...@lounge.org] >> > >> Sent: Wednesday, March 03, 2010 3:39 PM >> > >> To: Hoeper Katrin-QWKN37 >> > >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org >> > >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> > >> >> > >> >> > >> Hi Katrin, >> > >> >> > >> On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: >> > >> > Dan, >> > >> > >> > >> > OK, I understand that the tunnel provides all these other > feats. >> > >> > >> > >> > But why can't the server authenticate during the tunnel > protocol? >> I >> > >> > still don't understand the use case for mutually anonymous >> tunnels. >> > >> >> > >> Because it doesn't have the right credential. >> > >> >> > >> > If the server has a certificate why can't it send it to the > peer >> > > before >> > >> > or during the tunnel establishment? >> > >> >> > >> If the server has a certificate then sending it to the peer >> > >> would not really solve any problem. The peer would still need to >> > >> have a reason to trust it and we're back to the problem of > putting >> > >> a trusted certificate in some certificate store. A global PKI to >> > >> solve all of our certificate issues still has not materialized. >> > >> >> > >> > If the peer and server share a secret, than this could be used > to >> > >> > establish the tunnel. >> > >> >> > >> If the peer and server share a secret they could use one of the >> PSK >> > >> ciphersuites for TLS but those are susceptible to a dictionary >> attack >> > >> and are therefore inappropriate. >> > >> >> > >> The tunnel is being established with EAP-TLS so we are limited > to >> > >> TLS ciphersuites and the authentication they provide. If a TLS >> > > ciphersuite >> > >> was appropriate always and everywhere then we would not need any >> other >> > >> EAP methods, we'd just do EAP-TLS. But that is not the case. Also >> it >> > > is >> > >> a requirement to tunnel additional EAP methods inside the tunnel > so >> > >> obviously there are EAP methods that provide something that a TLS >> > >> ciphersuite does not. >> > >> >> > >> > What I am saying is what kind of server authentication >> credentials >> > > could >> > >> > be used inside an anonymous tunnel that could not be used to >> > >> > authenticate the server in the tunnel protocol? (given that >> privacy >> > > is >> > >> > not the issue) >> > >> >> > >> A low-entropy password that can easily be remembered and > entered >> by >> > > a >> > >> human with low probability of error. >> > > [KH] I asked what kind of SERVER credentials not peer credentials. >> > >> >> > >> Dan. >> > >> >> > > >> > > >> > >> >> ___ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Sorry Dan, Is EAP-pwd using the password for mutual authentication? > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Hoeper Katrin-QWKN37 > Sent: Wednesday, March 03, 2010 4:28 PM > To: Dan Harkins > Cc: emu@ietf.org > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > How does that authenticate the server if a user enters a password? > > If the server says, yes that was the right password? > > > > > -Original Message- > > From: Dan Harkins [mailto:dhark...@lounge.org] > > Sent: Wednesday, March 03, 2010 4:14 PM > > To: Hoeper Katrin-QWKN37 > > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > > > Since they both use the same low-entropy password to perform their > > mutual authentication it is not, strictly speaking, just the peer's > > credential. > > > > Dan. > > > > On Wed, March 3, 2010 1:45 pm, Hoeper Katrin-QWKN37 wrote: > > > > > > See inline. > > >> -Original Message- > > >> From: Dan Harkins [mailto:dhark...@lounge.org] > > >> Sent: Wednesday, March 03, 2010 3:39 PM > > >> To: Hoeper Katrin-QWKN37 > > >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > > >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > >> > > >> > > >> Hi Katrin, > > >> > > >> On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: > > >> > Dan, > > >> > > > >> > OK, I understand that the tunnel provides all these other feats. > > >> > > > >> > But why can't the server authenticate during the tunnel protocol? > I > > >> > still don't understand the use case for mutually anonymous > tunnels. > > >> > > >> Because it doesn't have the right credential. > > >> > > >> > If the server has a certificate why can't it send it to the peer > > > before > > >> > or during the tunnel establishment? > > >> > > >> If the server has a certificate then sending it to the peer > > >> would not really solve any problem. The peer would still need to > > >> have a reason to trust it and we're back to the problem of putting > > >> a trusted certificate in some certificate store. A global PKI to > > >> solve all of our certificate issues still has not materialized. > > >> > > >> > If the peer and server share a secret, than this could be used to > > >> > establish the tunnel. > > >> > > >> If the peer and server share a secret they could use one of the > PSK > > >> ciphersuites for TLS but those are susceptible to a dictionary > attack > > >> and are therefore inappropriate. > > >> > > >> The tunnel is being established with EAP-TLS so we are limited to > > >> TLS ciphersuites and the authentication they provide. If a TLS > > > ciphersuite > > >> was appropriate always and everywhere then we would not need any > other > > >> EAP methods, we'd just do EAP-TLS. But that is not the case. Also > it > > > is > > >> a requirement to tunnel additional EAP methods inside the tunnel so > > >> obviously there are EAP methods that provide something that a TLS > > >> ciphersuite does not. > > >> > > >> > What I am saying is what kind of server authentication > credentials > > > could > > >> > be used inside an anonymous tunnel that could not be used to > > >> > authenticate the server in the tunnel protocol? (given that > privacy > > > is > > >> > not the issue) > > >> > > >> A low-entropy password that can easily be remembered and entered > by > > > a > > >> human with low probability of error. > > > [KH] I asked what kind of SERVER credentials not peer credentials. > > >> > > >> Dan. > > >> > > > > > > > > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
How does that authenticate the server if a user enters a password? If the server says, yes that was the right password? > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, March 03, 2010 4:14 PM > To: Hoeper Katrin-QWKN37 > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Since they both use the same low-entropy password to perform their > mutual authentication it is not, strictly speaking, just the peer's > credential. > > Dan. > > On Wed, March 3, 2010 1:45 pm, Hoeper Katrin-QWKN37 wrote: > > > > See inline. > >> -Original Message- > >> From: Dan Harkins [mailto:dhark...@lounge.org] > >> Sent: Wednesday, March 03, 2010 3:39 PM > >> To: Hoeper Katrin-QWKN37 > >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > >> > >> Hi Katrin, > >> > >> On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: > >> > Dan, > >> > > >> > OK, I understand that the tunnel provides all these other feats. > >> > > >> > But why can't the server authenticate during the tunnel protocol? I > >> > still don't understand the use case for mutually anonymous tunnels. > >> > >> Because it doesn't have the right credential. > >> > >> > If the server has a certificate why can't it send it to the peer > > before > >> > or during the tunnel establishment? > >> > >> If the server has a certificate then sending it to the peer > >> would not really solve any problem. The peer would still need to > >> have a reason to trust it and we're back to the problem of putting > >> a trusted certificate in some certificate store. A global PKI to > >> solve all of our certificate issues still has not materialized. > >> > >> > If the peer and server share a secret, than this could be used to > >> > establish the tunnel. > >> > >> If the peer and server share a secret they could use one of the PSK > >> ciphersuites for TLS but those are susceptible to a dictionary attack > >> and are therefore inappropriate. > >> > >> The tunnel is being established with EAP-TLS so we are limited to > >> TLS ciphersuites and the authentication they provide. If a TLS > > ciphersuite > >> was appropriate always and everywhere then we would not need any other > >> EAP methods, we'd just do EAP-TLS. But that is not the case. Also it > > is > >> a requirement to tunnel additional EAP methods inside the tunnel so > >> obviously there are EAP methods that provide something that a TLS > >> ciphersuite does not. > >> > >> > What I am saying is what kind of server authentication credentials > > could > >> > be used inside an anonymous tunnel that could not be used to > >> > authenticate the server in the tunnel protocol? (given that privacy > > is > >> > not the issue) > >> > >> A low-entropy password that can easily be remembered and entered by > > a > >> human with low probability of error. > > [KH] I asked what kind of SERVER credentials not peer credentials. > >> > >> Dan. > >> > > > > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Since they both use the same low-entropy password to perform their mutual authentication it is not, strictly speaking, just the peer's credential. Dan. On Wed, March 3, 2010 1:45 pm, Hoeper Katrin-QWKN37 wrote: > > See inline. >> -Original Message- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Wednesday, March 03, 2010 3:39 PM >> To: Hoeper Katrin-QWKN37 >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> >> >> Hi Katrin, >> >> On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: >> > Dan, >> > >> > OK, I understand that the tunnel provides all these other feats. >> > >> > But why can't the server authenticate during the tunnel protocol? I >> > still don't understand the use case for mutually anonymous tunnels. >> >> Because it doesn't have the right credential. >> >> > If the server has a certificate why can't it send it to the peer > before >> > or during the tunnel establishment? >> >> If the server has a certificate then sending it to the peer >> would not really solve any problem. The peer would still need to >> have a reason to trust it and we're back to the problem of putting >> a trusted certificate in some certificate store. A global PKI to >> solve all of our certificate issues still has not materialized. >> >> > If the peer and server share a secret, than this could be used to >> > establish the tunnel. >> >> If the peer and server share a secret they could use one of the PSK >> ciphersuites for TLS but those are susceptible to a dictionary attack >> and are therefore inappropriate. >> >> The tunnel is being established with EAP-TLS so we are limited to >> TLS ciphersuites and the authentication they provide. If a TLS > ciphersuite >> was appropriate always and everywhere then we would not need any other >> EAP methods, we'd just do EAP-TLS. But that is not the case. Also it > is >> a requirement to tunnel additional EAP methods inside the tunnel so >> obviously there are EAP methods that provide something that a TLS >> ciphersuite does not. >> >> > What I am saying is what kind of server authentication credentials > could >> > be used inside an anonymous tunnel that could not be used to >> > authenticate the server in the tunnel protocol? (given that privacy > is >> > not the issue) >> >> A low-entropy password that can easily be remembered and entered by > a >> human with low probability of error. > [KH] I asked what kind of SERVER credentials not peer credentials. >> >> Dan. >> > > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
See inline. > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, March 03, 2010 3:39 PM > To: Hoeper Katrin-QWKN37 > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hi Katrin, > > On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: > > Dan, > > > > OK, I understand that the tunnel provides all these other feats. > > > > But why can't the server authenticate during the tunnel protocol? I > > still don't understand the use case for mutually anonymous tunnels. > > Because it doesn't have the right credential. > > > If the server has a certificate why can't it send it to the peer before > > or during the tunnel establishment? > > If the server has a certificate then sending it to the peer > would not really solve any problem. The peer would still need to > have a reason to trust it and we're back to the problem of putting > a trusted certificate in some certificate store. A global PKI to > solve all of our certificate issues still has not materialized. > > > If the peer and server share a secret, than this could be used to > > establish the tunnel. > > If the peer and server share a secret they could use one of the PSK > ciphersuites for TLS but those are susceptible to a dictionary attack > and are therefore inappropriate. > > The tunnel is being established with EAP-TLS so we are limited to > TLS ciphersuites and the authentication they provide. If a TLS ciphersuite > was appropriate always and everywhere then we would not need any other > EAP methods, we'd just do EAP-TLS. But that is not the case. Also it is > a requirement to tunnel additional EAP methods inside the tunnel so > obviously there are EAP methods that provide something that a TLS > ciphersuite does not. > > > What I am saying is what kind of server authentication credentials could > > be used inside an anonymous tunnel that could not be used to > > authenticate the server in the tunnel protocol? (given that privacy is > > not the issue) > > A low-entropy password that can easily be remembered and entered by a > human with low probability of error. [KH] I asked what kind of SERVER credentials not peer credentials. > > Dan. > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Katrin, On Wed, March 3, 2010 12:31 pm, Hoeper Katrin-QWKN37 wrote: > Dan, > > OK, I understand that the tunnel provides all these other feats. > > But why can't the server authenticate during the tunnel protocol? I > still don't understand the use case for mutually anonymous tunnels. Because it doesn't have the right credential. > If the server has a certificate why can't it send it to the peer before > or during the tunnel establishment? If the server has a certificate then sending it to the peer would not really solve any problem. The peer would still need to have a reason to trust it and we're back to the problem of putting a trusted certificate in some certificate store. A global PKI to solve all of our certificate issues still has not materialized. > If the peer and server share a secret, than this could be used to > establish the tunnel. If the peer and server share a secret they could use one of the PSK ciphersuites for TLS but those are susceptible to a dictionary attack and are therefore inappropriate. The tunnel is being established with EAP-TLS so we are limited to TLS ciphersuites and the authentication they provide. If a TLS ciphersuite was appropriate always and everywhere then we would not need any other EAP methods, we'd just do EAP-TLS. But that is not the case. Also it is a requirement to tunnel additional EAP methods inside the tunnel so obviously there are EAP methods that provide something that a TLS ciphersuite does not. > What I am saying is what kind of server authentication credentials could > be used inside an anonymous tunnel that could not be used to > authenticate the server in the tunnel protocol? (given that privacy is > not the issue) A low-entropy password that can easily be remembered and entered by a human with low probability of error. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Dan, OK, I understand that the tunnel provides all these other feats. But why can't the server authenticate during the tunnel protocol? I still don't understand the use case for mutually anonymous tunnels. If the server has a certificate why can't it send it to the peer before or during the tunnel establishment? If the peer and server share a secret, than this could be used to establish the tunnel. What I am saying is what kind of server authentication credentials could be used inside an anonymous tunnel that could not be used to authenticate the server in the tunnel protocol? (given that privacy is not the issue) Katrin > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, March 03, 2010 1:20 PM > To: Hoeper Katrin-QWKN37 > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hi Katrin, > > The tunneled method for which these requirements are being defined > will do more than simply authentication. Sections 3.6 and 3.8 are a > good example. It is not possible to do these things with an EAP method > that, while generating a strong secret and being resistant to dictionary > attack, just does authentication (viz, EAP-pwd). > > So the existence of the tunnel is being leveraged to do all this other > stuff: "additional data related to authentication, authorization > and network access can be carried inside the tunnel". That's the benefit. > It's the tunnel, not the anonymity of the tunnel. And since all this > extra stuff will be protected by a key generated per section 4.6.3 then > we have security and utility (at the modest cost of a potential loss of > identity). > > regards, > > Dan. > > On Wed, March 3, 2010 10:25 am, Hoeper Katrin-QWKN37 wrote: > > Dan, > > > > So you say that there are use cases for mutually anonymous tunnels > > besides providing privacy (b/c as we have established they don't provide > > that). > > > > You use credential provisioning as an example. However, in your example, > > a server's certificate does not need to be pre-installed on a peer, > > instead a root certificate of the CA is sufficient to be able to verify > > the server's certificate. How does the mutually anonymous tunnel address > > the problem of installing root certificates? Certificates can be send > > outside tunnels if privacy is no concern. > > > > > > OK, let's assume there are valid use cases, then the conditions for the > > inner methods must be: > > > > -strong mutual authentication > > -strong key establishment > > > > > > Among other things, strong implies there can't be any OFF-LINE > > dictionary attacks. > > > > Most importantly, such an inner method does not need to be protected by > > a tunnel! > > > > I still don't understand what good this anonymous tunnel does for > > credential provisioning. > > > > Katrin > > > > > >> -Original Message- > >> From: Dan Harkins [mailto:dhark...@lounge.org] > >> Sent: Wednesday, March 03, 2010 11:54 AM > >> To: Hoeper Katrin-QWKN37 > >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > >> > >> Hi Katrin, > >> > >> Let's not consider methods that derive no keys or do weak key > >> establishment. We can make say that you MUST use an exchange that > >> performs mutual authentication, generates a strong key, and is > >> resistant to dictionary attack. > >> > >> So all that's left is an "attack" that learns the identities used > >> in the exchange, that is all. Identity protection may be important to > >> some people but it may not be important to some other people. More > >> importantly, potentially exposing one's identity may be a completely > >> reasonable price to pay to get the value this combination supplies. > >> It would be prudent to mention the lack of identity protection when > >> using an anonymous tunnel + strong inner EAP method but forbidding it > >> because someone else may not want their identity known is overkill. > >> > >> Credential provisioning is currently a MUST in the draft. How does > >> one do initial credential provisioning? Do we always assume that > >> a trusted certificate of the server has been properly installed on > >> the client's computer prior to initial authentication for this > >> "cr
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Katrin, The tunneled method for which these requirements are being defined will do more than simply authentication. Sections 3.6 and 3.8 are a good example. It is not possible to do these things with an EAP method that, while generating a strong secret and being resistant to dictionary attack, just does authentication (viz, EAP-pwd). So the existence of the tunnel is being leveraged to do all this other stuff: "additional data related to authentication, authorization and network access can be carried inside the tunnel". That's the benefit. It's the tunnel, not the anonymity of the tunnel. And since all this extra stuff will be protected by a key generated per section 4.6.3 then we have security and utility (at the modest cost of a potential loss of identity). regards, Dan. On Wed, March 3, 2010 10:25 am, Hoeper Katrin-QWKN37 wrote: > Dan, > > So you say that there are use cases for mutually anonymous tunnels > besides providing privacy (b/c as we have established they don't provide > that). > > You use credential provisioning as an example. However, in your example, > a server's certificate does not need to be pre-installed on a peer, > instead a root certificate of the CA is sufficient to be able to verify > the server's certificate. How does the mutually anonymous tunnel address > the problem of installing root certificates? Certificates can be send > outside tunnels if privacy is no concern. > > > OK, let's assume there are valid use cases, then the conditions for the > inner methods must be: > > -strong mutual authentication > -strong key establishment > > > Among other things, strong implies there can't be any OFF-LINE > dictionary attacks. > > Most importantly, such an inner method does not need to be protected by > a tunnel! > > I still don't understand what good this anonymous tunnel does for > credential provisioning. > > Katrin > > >> -Original Message- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Wednesday, March 03, 2010 11:54 AM >> To: Hoeper Katrin-QWKN37 >> Cc: Dan Harkins; Joseph Salowey; emu@ietf.org >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> >> >> Hi Katrin, >> >> Let's not consider methods that derive no keys or do weak key >> establishment. We can make say that you MUST use an exchange that >> performs mutual authentication, generates a strong key, and is >> resistant to dictionary attack. >> >> So all that's left is an "attack" that learns the identities used >> in the exchange, that is all. Identity protection may be important to >> some people but it may not be important to some other people. More >> importantly, potentially exposing one's identity may be a completely >> reasonable price to pay to get the value this combination supplies. >> It would be prudent to mention the lack of identity protection when >> using an anonymous tunnel + strong inner EAP method but forbidding it >> because someone else may not want their identity known is overkill. >> >> Credential provisioning is currently a MUST in the draft. How does >> one do initial credential provisioning? Do we always assume that >> a trusted certificate of the server has been properly installed on >> the client's computer prior to initial authentication for this >> "credential provisioning" to work? That assumption has not worked at >> all in the past (which is why there's a "do not verify server cert" >> checkbox in the GUI of the OS with 90+% of the market) and there is >> no reason to assume it will start working now. >> >> A better course would be to not have unrealistic assumptions. Have >> realistic assumptions and state them. I suggest: >> >> - if an anonymous tunnel is established an inner method MUST perform >> mutual authentication, generates keys and be resistant to > dictionary >> attack. >> - a man-in-the-middle attack would fail upon completion of the >> inner method but the identities exchanged inside the anonymous >> tunnel would be known to an attacker. >> >> We should not let the good be the enemy of the best. Security is > about >> risk management and we should allow people to manage their risk. >> >> regards, >> >> Dan. >> >> On Wed, March 3, 2010 7:00 am, Hoeper Katrin-QWKN37 wrote: >> > Hi Dan, >> > >> > It is not secure, even *with* cryptographic bindings. >> > >> > The very least a MitM attacker can do is get the identities of both >> > par
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Dan, So you say that there are use cases for mutually anonymous tunnels besides providing privacy (b/c as we have established they don't provide that). You use credential provisioning as an example. However, in your example, a server's certificate does not need to be pre-installed on a peer, instead a root certificate of the CA is sufficient to be able to verify the server's certificate. How does the mutually anonymous tunnel address the problem of installing root certificates? Certificates can be send outside tunnels if privacy is no concern. OK, let's assume there are valid use cases, then the conditions for the inner methods must be: -strong mutual authentication -strong key establishment Among other things, strong implies there can't be any OFF-LINE dictionary attacks. Most importantly, such an inner method does not need to be protected by a tunnel! I still don't understand what good this anonymous tunnel does for credential provisioning. Katrin > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Wednesday, March 03, 2010 11:54 AM > To: Hoeper Katrin-QWKN37 > Cc: Dan Harkins; Joseph Salowey; emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hi Katrin, > > Let's not consider methods that derive no keys or do weak key > establishment. We can make say that you MUST use an exchange that > performs mutual authentication, generates a strong key, and is > resistant to dictionary attack. > > So all that's left is an "attack" that learns the identities used > in the exchange, that is all. Identity protection may be important to > some people but it may not be important to some other people. More > importantly, potentially exposing one's identity may be a completely > reasonable price to pay to get the value this combination supplies. > It would be prudent to mention the lack of identity protection when > using an anonymous tunnel + strong inner EAP method but forbidding it > because someone else may not want their identity known is overkill. > > Credential provisioning is currently a MUST in the draft. How does > one do initial credential provisioning? Do we always assume that > a trusted certificate of the server has been properly installed on > the client's computer prior to initial authentication for this > "credential provisioning" to work? That assumption has not worked at > all in the past (which is why there's a "do not verify server cert" > checkbox in the GUI of the OS with 90+% of the market) and there is > no reason to assume it will start working now. > > A better course would be to not have unrealistic assumptions. Have > realistic assumptions and state them. I suggest: > > - if an anonymous tunnel is established an inner method MUST perform > mutual authentication, generates keys and be resistant to dictionary > attack. > - a man-in-the-middle attack would fail upon completion of the > inner method but the identities exchanged inside the anonymous > tunnel would be known to an attacker. > > We should not let the good be the enemy of the best. Security is about > risk management and we should allow people to manage their risk. > > regards, > > Dan. > > On Wed, March 3, 2010 7:00 am, Hoeper Katrin-QWKN37 wrote: > > Hi Dan, > > > > It is not secure, even *with* cryptographic bindings. > > > > The very least a MitM attacker can do is get the identities of both > > parties exchanged inside the tunnel -> i.e. breaking the privacy of both > > parties and thus rendering the anonymous tunnel useless. This is > > *always* possible! > > > > If the inner method derives no keys or has a weak key establishment, > > then the MitM can break the entire session, deriving all keys and > > staying undetected while listening to the rest of the session. > > > > Considering the attack, I don't see what mutually anonymous tunnels can > > achieve what a server-authenticated tunnels couldn't. > > I guess you need to convince me of the value of mutually anonymous > > tunnels in which an MitM can get all exchanged identifiers in order to > > change my mind :) > > > > The attack is described in the reference I provided in my last email. > > NIST SP 800-120 does no permit mutually anonymous tunnels for exactly > > that reason. > > > > And our requirements draft shouldn't either. > > > > Katrin > > > > PS: If you want to talk about using certified pseudonyms, that is a > > different story. > > > >
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Katrin, Let's not consider methods that derive no keys or do weak key establishment. We can make say that you MUST use an exchange that performs mutual authentication, generates a strong key, and is resistant to dictionary attack. So all that's left is an "attack" that learns the identities used in the exchange, that is all. Identity protection may be important to some people but it may not be important to some other people. More importantly, potentially exposing one's identity may be a completely reasonable price to pay to get the value this combination supplies. It would be prudent to mention the lack of identity protection when using an anonymous tunnel + strong inner EAP method but forbidding it because someone else may not want their identity known is overkill. Credential provisioning is currently a MUST in the draft. How does one do initial credential provisioning? Do we always assume that a trusted certificate of the server has been properly installed on the client's computer prior to initial authentication for this "credential provisioning" to work? That assumption has not worked at all in the past (which is why there's a "do not verify server cert" checkbox in the GUI of the OS with 90+% of the market) and there is no reason to assume it will start working now. A better course would be to not have unrealistic assumptions. Have realistic assumptions and state them. I suggest: - if an anonymous tunnel is established an inner method MUST perform mutual authentication, generates keys and be resistant to dictionary attack. - a man-in-the-middle attack would fail upon completion of the inner method but the identities exchanged inside the anonymous tunnel would be known to an attacker. We should not let the good be the enemy of the best. Security is about risk management and we should allow people to manage their risk. regards, Dan. On Wed, March 3, 2010 7:00 am, Hoeper Katrin-QWKN37 wrote: > Hi Dan, > > It is not secure, even *with* cryptographic bindings. > > The very least a MitM attacker can do is get the identities of both > parties exchanged inside the tunnel -> i.e. breaking the privacy of both > parties and thus rendering the anonymous tunnel useless. This is > *always* possible! > > If the inner method derives no keys or has a weak key establishment, > then the MitM can break the entire session, deriving all keys and > staying undetected while listening to the rest of the session. > > Considering the attack, I don't see what mutually anonymous tunnels can > achieve what a server-authenticated tunnels couldn't. > I guess you need to convince me of the value of mutually anonymous > tunnels in which an MitM can get all exchanged identifiers in order to > change my mind :) > > The attack is described in the reference I provided in my last email. > NIST SP 800-120 does no permit mutually anonymous tunnels for exactly > that reason. > > And our requirements draft shouldn't either. > > Katrin > > PS: If you want to talk about using certified pseudonyms, that is a > different story. > > > - > Details of the attack (for a complete discussion, please read the paper) > > The MitM attacker establishes a tunnel with the peer and another one > with the server using a mutually anonymous tunnel protocol. > The peer authentication and server authentication now takes place inside > the two tunnel segments. The MitM needs to decrypt and re-encrypt all > messages in order to forward a message from one tunnel into the other > tunnel. Server and peer would not notice. > The MitM does *not* impersonate any party but has full access to all > information inside the tunnel, including the exchanged identifiers. > > Let's say crypto bindings are used. Only if the derived inner key IK > cannot be derived by the MitM, i.e. the key derivation algorithm is > cryptographically strong, the attack will be detected. However, by then > the MitM is already in possession of the identifiers that have been > "anonymously" exchanged inside the tunnel. Besides, many inner methods > only have weak inner key derivations (that's why they are tunneled) or > do not derive a key at all. In these cases, the attacker is able to > derive the cryptographic bindings for both tunnel segments and keep > fooling peer and server. > > > > >> -Original Message- >> From: Dan Harkins [mailto:dhark...@lounge.org] >> Sent: Tuesday, March 02, 2010 7:10 PM >> To: Hoeper Katrin-QWKN37 >> Cc: Joseph Salowey; Dan Harkins; emu@ietf.org >> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> >> >> Hi Katrin, >&g
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Dan, It is not secure, even *with* cryptographic bindings. The very least a MitM attacker can do is get the identities of both parties exchanged inside the tunnel -> i.e. breaking the privacy of both parties and thus rendering the anonymous tunnel useless. This is *always* possible! If the inner method derives no keys or has a weak key establishment, then the MitM can break the entire session, deriving all keys and staying undetected while listening to the rest of the session. Considering the attack, I don't see what mutually anonymous tunnels can achieve what a server-authenticated tunnels couldn't. I guess you need to convince me of the value of mutually anonymous tunnels in which an MitM can get all exchanged identifiers in order to change my mind :) The attack is described in the reference I provided in my last email. NIST SP 800-120 does no permit mutually anonymous tunnels for exactly that reason. And our requirements draft shouldn't either. Katrin PS: If you want to talk about using certified pseudonyms, that is a different story. - Details of the attack (for a complete discussion, please read the paper) The MitM attacker establishes a tunnel with the peer and another one with the server using a mutually anonymous tunnel protocol. The peer authentication and server authentication now takes place inside the two tunnel segments. The MitM needs to decrypt and re-encrypt all messages in order to forward a message from one tunnel into the other tunnel. Server and peer would not notice. The MitM does *not* impersonate any party but has full access to all information inside the tunnel, including the exchanged identifiers. Let's say crypto bindings are used. Only if the derived inner key IK cannot be derived by the MitM, i.e. the key derivation algorithm is cryptographically strong, the attack will be detected. However, by then the MitM is already in possession of the identifiers that have been "anonymously" exchanged inside the tunnel. Besides, many inner methods only have weak inner key derivations (that's why they are tunneled) or do not derive a key at all. In these cases, the attacker is able to derive the cryptographic bindings for both tunnel segments and keep fooling peer and server. > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, March 02, 2010 7:10 PM > To: Hoeper Katrin-QWKN37 > Cc: Joseph Salowey; Dan Harkins; emu@ietf.org > Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hi Katrin, > > Section 4.6.3 will address a man-in-the-middle attack against an > anonymous TLS tunnel followed by a mutually-authenticating and key > generating EAP method, like EAP-pwd. The keying material from both > the anonymous tunnel and the tunneled EAP method will be mixed > together (according to 4.6.3) to derive an MSK and EMSK. > > The value is that such a technique can be used for initial credential > provisioning. And it is secure. Please reconsider your opposition to > allowing this technique. > > regards, > > Dan. > > On Tue, March 2, 2010 7:03 am, Hoeper Katrin-QWKN37 wrote: > > Dan, > > > > The current text allows server-side only authentication for the tunnel, > > i.e. the peer can remain anonymous during that phase and only transmit > > its credential inside the tunnel. This enables peer privacy. > > > > I think what you are talking about is mutually anonymous tunnels, i.e. > > both peer and server remain anonymous during the tunnel establishment. > > These types of tunnels are prone to man-in-the-middle attacks in which > > the privacy of both tunnel endpoints is compromised. I don't see any > > value of those anonymous tunnels. In fact they are not secure. > > > > I strongly oppose to allowing these tunnels and believe that the current > > text about this topic should be kept as is. > > > > Best regards, > > Katrin > > > > PS: Details on the mentioned MitM attacks are in > > http://portal.acm.org/citation.cfm?id=1577285 > > > > > > > >> -Original Message- > >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > >> Joseph Salowey (jsalowey) > >> Sent: Monday, March 01, 2010 11:53 PM > >> To: Dan Harkins; emu@ietf.org > >> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > >> > >> Thanks Dan, > >> > >> I haven't seen any responses on the list yet so I provided some inline > >> below. > >> > >> > -Original Message- > >> > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Beha
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Hi Katrin, Section 4.6.3 will address a man-in-the-middle attack against an anonymous TLS tunnel followed by a mutually-authenticating and key generating EAP method, like EAP-pwd. The keying material from both the anonymous tunnel and the tunneled EAP method will be mixed together (according to 4.6.3) to derive an MSK and EMSK. The value is that such a technique can be used for initial credential provisioning. And it is secure. Please reconsider your opposition to allowing this technique. regards, Dan. On Tue, March 2, 2010 7:03 am, Hoeper Katrin-QWKN37 wrote: > Dan, > > The current text allows server-side only authentication for the tunnel, > i.e. the peer can remain anonymous during that phase and only transmit > its credential inside the tunnel. This enables peer privacy. > > I think what you are talking about is mutually anonymous tunnels, i.e. > both peer and server remain anonymous during the tunnel establishment. > These types of tunnels are prone to man-in-the-middle attacks in which > the privacy of both tunnel endpoints is compromised. I don't see any > value of those anonymous tunnels. In fact they are not secure. > > I strongly oppose to allowing these tunnels and believe that the current > text about this topic should be kept as is. > > Best regards, > Katrin > > PS: Details on the mentioned MitM attacks are in > http://portal.acm.org/citation.cfm?id=1577285 > > > >> -Original Message- >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >> Joseph Salowey (jsalowey) >> Sent: Monday, March 01, 2010 11:53 PM >> To: Dan Harkins; emu@ietf.org >> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> >> Thanks Dan, >> >> I haven't seen any responses on the list yet so I provided some inline >> below. >> >> > -Original Message- >> > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf > Of >> Dan >> > Harkins >> > Sent: Monday, November 30, 2009 12:57 PM >> > To: emu@ietf.org >> > Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04 >> > >> > >> > Hello, >> > >> > I made some of these comments at the mic in Hiroshima but was >> > asked to submit them to the list. >> > >> > - I get the feeling that this document is being written to >> > ensure some end-game and not simply as a protocol requirements >> > document. >> > >> > I mentioned that it would be nice if the tunneled method >> > described a way to establish an EAP-TLS -style connection, >> > either anonymous or server-side-auth-only, and then allow >> > for subsequent authentication using another EAP method (or >> > using specific TLVs for some password authentication) or >> > EAP methods chained together by the tunnel. Pasi said that >> > is the intention but it sure doesn't seem that way. >> > >> [Joe] Currently the scope of the work does not include anonymous >> authentication. I think this could be follow-on work to the tunnel >> method. I don't think the current document should prohibit anonymous >> cipher suites from being used in follow-on specifications. See the >> response to 4.2.1.1.3 for some suggested text. >> >> > - section 3.4 states that the tunnel method MUST ensure "that >> > peer identity is not disclosed to the authenticator and any >> > other intermediaries before the server that terminates the >> > tunnel method." >> > >> > EAP is supposed to be a 2 party protocol that, for optimization, >> > can have functionality split between a pass-thru authenticator >> > and a EAP method-terminating server. But it seems wrong to >> > put forth the optimization as if it's a requirement for the >> > tunnel method. >> > >> > Please change this to something like "the identity of the peer >> > used for authentication purposes MUST NOT be obtainable by any >> > entity other than the EAP server terminating the tunnel method." >> > >> [Joe] OK >> >> > - 3.6 seems somewhat pointless. "The tunnel method SHOULD support >> > carrying of NEA protocols" and "these protocols may be required >> > to be carried in an EAP method." >> > >> > Since the tunneled EAP method can tunnel EAP methods then this >> > "requirement" should just naturally flow out of another >> requirement. >&g
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Dan, The current text allows server-side only authentication for the tunnel, i.e. the peer can remain anonymous during that phase and only transmit its credential inside the tunnel. This enables peer privacy. I think what you are talking about is mutually anonymous tunnels, i.e. both peer and server remain anonymous during the tunnel establishment. These types of tunnels are prone to man-in-the-middle attacks in which the privacy of both tunnel endpoints is compromised. I don't see any value of those anonymous tunnels. In fact they are not secure. I strongly oppose to allowing these tunnels and believe that the current text about this topic should be kept as is. Best regards, Katrin PS: Details on the mentioned MitM attacks are in http://portal.acm.org/citation.cfm?id=1577285 > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Monday, March 01, 2010 11:53 PM > To: Dan Harkins; emu@ietf.org > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > Thanks Dan, > > I haven't seen any responses on the list yet so I provided some inline > below. > > > -Original Message- > > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Dan > > Harkins > > Sent: Monday, November 30, 2009 12:57 PM > > To: emu@ietf.org > > Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > > > > Hello, > > > > I made some of these comments at the mic in Hiroshima but was > > asked to submit them to the list. > > > > - I get the feeling that this document is being written to > > ensure some end-game and not simply as a protocol requirements > > document. > > > > I mentioned that it would be nice if the tunneled method > > described a way to establish an EAP-TLS -style connection, > > either anonymous or server-side-auth-only, and then allow > > for subsequent authentication using another EAP method (or > > using specific TLVs for some password authentication) or > > EAP methods chained together by the tunnel. Pasi said that > > is the intention but it sure doesn't seem that way. > > > [Joe] Currently the scope of the work does not include anonymous > authentication. I think this could be follow-on work to the tunnel > method. I don't think the current document should prohibit anonymous > cipher suites from being used in follow-on specifications. See the > response to 4.2.1.1.3 for some suggested text. > > > - section 3.4 states that the tunnel method MUST ensure "that > > peer identity is not disclosed to the authenticator and any > > other intermediaries before the server that terminates the > > tunnel method." > > > > EAP is supposed to be a 2 party protocol that, for optimization, > > can have functionality split between a pass-thru authenticator > > and a EAP method-terminating server. But it seems wrong to > > put forth the optimization as if it's a requirement for the > > tunnel method. > > > > Please change this to something like "the identity of the peer > > used for authentication purposes MUST NOT be obtainable by any > > entity other than the EAP server terminating the tunnel method." > > > [Joe] OK > > > - 3.6 seems somewhat pointless. "The tunnel method SHOULD support > > carrying of NEA protocols" and "these protocols may be required > > to be carried in an EAP method." > > > > Since the tunneled EAP method can tunnel EAP methods then this > > "requirement" should just naturally flow out of another > requirement. > > Please remove section 3.6. > > > [Joe] While, it is true that carrying NEA protocols should be met by > either the extensibility or carrying EAP method requirements, I believe > that NEA use case is pertinent to the tunnel method work and should be > mentioned somewhere in the document. What is the harm in mentioning it > here? > > > - 3.7 describes "credentials [that] may only partially authenticate > > the identity of the peer". > > > > Huh? What kind of credentials are these? Please describe these > > credentials. > > > [Joe] OK > > > Additionally, "the tunnel may be used to communicate additional > > data". > > > > This is so vague as to be meaningless. A nonce could satisfy > > this "requirement", and so could 8 bits of RESERVED-- set to zero > > before transm
Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
Thanks Dan, I haven't seen any responses on the list yet so I provided some inline below. > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of Dan > Harkins > Sent: Monday, November 30, 2009 12:57 PM > To: emu@ietf.org > Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04 > > > Hello, > > I made some of these comments at the mic in Hiroshima but was > asked to submit them to the list. > > - I get the feeling that this document is being written to > ensure some end-game and not simply as a protocol requirements > document. > > I mentioned that it would be nice if the tunneled method > described a way to establish an EAP-TLS -style connection, > either anonymous or server-side-auth-only, and then allow > for subsequent authentication using another EAP method (or > using specific TLVs for some password authentication) or > EAP methods chained together by the tunnel. Pasi said that > is the intention but it sure doesn't seem that way. > [Joe] Currently the scope of the work does not include anonymous authentication. I think this could be follow-on work to the tunnel method. I don't think the current document should prohibit anonymous cipher suites from being used in follow-on specifications. See the response to 4.2.1.1.3 for some suggested text. > - section 3.4 states that the tunnel method MUST ensure "that > peer identity is not disclosed to the authenticator and any > other intermediaries before the server that terminates the > tunnel method." > > EAP is supposed to be a 2 party protocol that, for optimization, > can have functionality split between a pass-thru authenticator > and a EAP method-terminating server. But it seems wrong to > put forth the optimization as if it's a requirement for the > tunnel method. > > Please change this to something like "the identity of the peer > used for authentication purposes MUST NOT be obtainable by any > entity other than the EAP server terminating the tunnel method." > [Joe] OK > - 3.6 seems somewhat pointless. "The tunnel method SHOULD support > carrying of NEA protocols" and "these protocols may be required > to be carried in an EAP method." > > Since the tunneled EAP method can tunnel EAP methods then this > "requirement" should just naturally flow out of another requirement. > Please remove section 3.6. > [Joe] While, it is true that carrying NEA protocols should be met by either the extensibility or carrying EAP method requirements, I believe that NEA use case is pertinent to the tunnel method work and should be mentioned somewhere in the document. What is the harm in mentioning it here? > - 3.7 describes "credentials [that] may only partially authenticate > the identity of the peer". > > Huh? What kind of credentials are these? Please describe these > credentials. > [Joe] OK > Additionally, "the tunnel may be used to communicate additional > data". > > This is so vague as to be meaningless. A nonce could satisfy > this "requirement", and so could 8 bits of RESERVED-- set to zero > before transmitting and ignored upon receipt-- for that matter. > Please remove this. > [Joe] Removed > - 3.8 mentions a use of "extensibility is support for authentication > frameworks other than EAP." > > That seems like a huge stretch of the work we are chartered to do. > I suggest that line be removed. > [Joe] Alan had a similar comment that this text is confusing. The suggest text is: " Another use for extensibility is support for alternate authentication frameworks within the tunnel." > - 4.1.2 is inappropriate. It is not the purpose of a document describing > the requirements for a protocol to direct the working group how to > evaluate potential protocols against those requirements. > > When I brought this up in Hiroshima a response was (I paraphrase), > "that the working group had consensus to use existing work and so > this is just a restatement of that consensus." Which raises another > interesting point without addressing my comment. That other point is > that if there is working group consensus then it is not necessary to > have section 4.1.2 then. The fact that 4.1.2 is in the document leads > one to believe that perhaps there is a fear that such support might > have evaporated. > > The working group does not need to be constrained in its decision- > making process. The process is defined and unde
[Emu] review of draft-ietf-emu-eaptunnel-req-04
Hello, I made some of these comments at the mic in Hiroshima but was asked to submit them to the list. - I get the feeling that this document is being written to ensure some end-game and not simply as a protocol requirements document. I mentioned that it would be nice if the tunneled method described a way to establish an EAP-TLS -style connection, either anonymous or server-side-auth-only, and then allow for subsequent authentication using another EAP method (or using specific TLVs for some password authentication) or EAP methods chained together by the tunnel. Pasi said that is the intention but it sure doesn't seem that way. - section 3.4 states that the tunnel method MUST ensure "that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method." EAP is supposed to be a 2 party protocol that, for optimization, can have functionality split between a pass-thru authenticator and a EAP method-terminating server. But it seems wrong to put forth the optimization as if it's a requirement for the tunnel method. Please change this to something like "the identity of the peer used for authentication purposes MUST NOT be obtainable by any entity other than the EAP server terminating the tunnel method." - 3.6 seems somewhat pointless. "The tunnel method SHOULD support carrying of NEA protocols" and "these protocols may be required to be carried in an EAP method." Since the tunneled EAP method can tunnel EAP methods then this "requirement" should just naturally flow out of another requirement. Please remove section 3.6. - 3.7 describes "credentials [that] may only partially authenticate the identity of the peer". Huh? What kind of credentials are these? Please describe these credentials. Additionally, "the tunnel may be used to communicate additional data". This is so vague as to be meaningless. A nonce could satisfy this "requirement", and so could 8 bits of RESERVED-- set to zero before transmitting and ignored upon receipt-- for that matter. Please remove this. - 3.8 mentions a use of "extensibility is support for authentication frameworks other than EAP." That seems like a huge stretch of the work we are chartered to do. I suggest that line be removed. - 4.1.2 is inappropriate. It is not the purpose of a document describing the requirements for a protocol to direct the working group how to evaluate potential protocols against those requirements. When I brought this up in Hiroshima a response was (I paraphrase), "that the working group had consensus to use existing work and so this is just a restatement of that consensus." Which raises another interesting point without addressing my comment. That other point is that if there is working group consensus then it is not necessary to have section 4.1.2 then. The fact that 4.1.2 is in the document leads one to believe that perhaps there is a fear that such support might have evaporated. The working group does not need to be constrained in its decision- making process. The process is defined and understood and it is inappropriate for a _protocol requirements document_ to say, "hey remember way back when a sample of active participants seemed to agree on a vague concept, well now you SHOULD select one of the two candidates here." Please remove 4.1.2. - 4.2.1.1.1 if TLS is required and "[a]ll versions of TLS meet [cipher suite negotiation] requirements" then what's the point of this section? Please remove section 4.2.1.1.1. - 4.2.1.1.3 begins saying "A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer and mutual authentication between authentication server and EAP peer." This is a nonsense statement. Either it's unidirectional or it's mutual, it can't be both. Additionally, it says "mandatory to implement cipher suites MUST NOT include...mutually anonymous authentication" Seeing as how this subsection is under 4.2.1 and 4.2.1.1.1 describes these as TLS cipher suites then I really think this should be changed. An anonymous TLS cipher suite negotiated by the EAP tunnel method will be extremely valuable when combined with something like EAP-pwd as the inner method. That would provide a way to securely satisfy the credential provisioning requirement (which is a MUST by the way). Please restate the requirement to say something along the lines of "if an anonymous TLS ciphersuite is used by the outer tunnel then an inner method providing mutual authentication MUST be used." - 4.2.1.2 requires replay protection and then goes on to say that TLS (which is required by 4.2.1) satisfies this requirement. Please remove 4.2.1.2
Re: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt
Alan, Thanks for your very thorough review. See my comments in-line. (I left a few comments for the other authors ;)) Katrin > -Original Message- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Alan DeKok > Sent: Tuesday, October 27, 2009 3:18 PM > To: emu@ietf.org > Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt > > > Here is my review of the tunnel requirements document. > > > 3. Use Cases > >To motivate and explain the requirements in this document, a >representative set of use cases for the EAP tunnel method are >supplied here. The candidate tunnel method is expected to support >all of the use cases marked as MUST. > > The last sentence is unclear. I would suggest saying: > >... >supplied here. The candidate tunnel method is expected to support >all of the use cases that are marked below as "MUST". > > The use of "is expected" makes it seem like it is not mandatory to > follow the following MUST requirements. But it would be > awkward to say > "it MUST support the MUSTs below". [KH] Agree that your version clarifies this. > > > 3.1. Password Authentication > >... The >combination of the tunnel authentication and password > authentication >MUST enable mutual authentication. > > Is the restriction on the *combination*? What is the tunnel > authentication method supports mutual authentication, and the password > authentication method does not? > > It may be better to say: > > The tunnel method MUST support mutual authentication [KH] Yes, we wanted to explicitly say that the *combination* (yes, emphasis on combination) of tunnel authentication and password authentication MUST enable mutual authentication. I don't see any problem with this sentence. Password-based authentications typically provide only peer authentication, whereas tunnel protocols typically only server authentication. A tunnel-based EAP method compliant with the draft, MUST enable mutual authentication if password-based authentication is used as an inner method. Password-based authentications are especially highlighted here because there are one of the primary use cases of tunneled authentications. > > 3.2. Protection of Weak EAP Methods > >Some existing EAP methods have vulnerabilities that could be >eliminated or reduced by running them inside a protected > tunnel. For >example, a method such as EAP-MD5 does not provide mutual > > > I would suggest deleting the text "a method such as". It > is redundant > with the previous "For example" phrase. > > [KH] OK >... In >particular, when weak methods are used, security policies enforcing >that such methods can only be executed inside a tunnel but never >outside one are required to mitigate the attack. > > This sentence is difficult to parse. I suggest: > >When weak methods are used, these attacks can be mitigated via >security policies that require the method to be used only within >a tunnel. > [KH] Sounds good. > >... On the other hand, >a technical solution (so-called cryptographic bindings) can be used >whenever the inner method is not susceptible to attacks outside a >tunnel and derives keying material. > > Is the final "and" a requirement for cryptographic bindings > to be used? [KH] Yes. > > 3.3. Chained EAP Methods > >Several circumstances are best addressed by using chained EAP >methods. For example, it may be desirable to authenticate the user >and also authenticate the device that he or she is using. > > Suggest replacing "he or she is using" with a passive voice "is being > used". [KH] OK > >... Cryptographic binding can be used to bind the results of key >generating methods together or to an encompassing tunnel. > > The previous sentences talk about chained methods rather than "key > generating" methods. I suggest replacing the above sentence with: > >.. Cryptographic binding can be used to bind chained methods >together, or to an encompassing tunnel. [KH] I think "...Cryptographic bindings can be used to bind key generating chained methods together, or to an encompassing tunnel" is more accurate because cryptographic bindings are only effective when applied to key generating methods. > > 3.4. Identity Protection > >When performing an EAP authentication, the peer may want to protect >its identity, only disclosing its identity to a trusted backend >authentication server. This helps to maintain the privacy of th
[Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt
Here is my review of the tunnel requirements document. 3. Use Cases To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are supplied here. The candidate tunnel method is expected to support all of the use cases marked as MUST. The last sentence is unclear. I would suggest saying: ... supplied here. The candidate tunnel method is expected to support all of the use cases that are marked below as "MUST". The use of "is expected" makes it seem like it is not mandatory to follow the following MUST requirements. But it would be awkward to say "it MUST support the MUSTs below". 3.1. Password Authentication ... The combination of the tunnel authentication and password authentication MUST enable mutual authentication. Is the restriction on the *combination*? What is the tunnel authentication method supports mutual authentication, and the password authentication method does not? It may be better to say: The tunnel method MUST support mutual authentication 3.2. Protection of Weak EAP Methods Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, a method such as EAP-MD5 does not provide mutual I would suggest deleting the text "a method such as". It is redundant with the previous "For example" phrase. ... In particular, when weak methods are used, security policies enforcing that such methods can only be executed inside a tunnel but never outside one are required to mitigate the attack. This sentence is difficult to parse. I suggest: When weak methods are used, these attacks can be mitigated via security policies that require the method to be used only within a tunnel. ... On the other hand, a technical solution (so-called cryptographic bindings) can be used whenever the inner method is not susceptible to attacks outside a tunnel and derives keying material. Is the final "and" a requirement for cryptographic bindings to be used? 3.3. Chained EAP Methods Several circumstances are best addressed by using chained EAP methods. For example, it may be desirable to authenticate the user and also authenticate the device that he or she is using. Suggest replacing "he or she is using" with a passive voice "is being used". ... Cryptographic binding can be used to bind the results of key generating methods together or to an encompassing tunnel. The previous sentences talk about chained methods rather than "key generating" methods. I suggest replacing the above sentence with: .. Cryptographic binding can be used to bind chained methods together, or to an encompassing tunnel. 3.4. Identity Protection When performing an EAP authentication, the peer may want to protect its identity, only disclosing its identity to a trusted backend authentication server. This helps to maintain the privacy of the peer's identity. This discussion seems redundant. Suggest replacing the text with: When performing an EAP authentication, the peer may want to protect its identity, and only disclose it to a trusted backend authentication server. This process helps to maintain peer privacy. The following text is unclear: The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method. The use of "before" is ambiguous. It could be interpreted as "intermediaries before the server...", rather than "before the tunnel has been terminated" Suggested text: The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to any intermediaries, or to the authenticator until the tunnel method has been completed. Continuing: 3.5. Anonymous Service Access When network service is provided, it is sometimes desirable for any user to be able to gain access to the network to enable access to limited services emergency communication or troubleshooting information. There are a lot of "to"'s in the above sentence. Suggested text: When network service is provided, it is sometimes desirable for a user to gain network access in order to use limited services emergency communication or access troubleshooting information. This paragraph contains two concepts. (1) requirements, and (2), security analysis derived from the requirements. Therefore, the tunnel method SHOULD allow anonymous peers or server- only authentication, but still derive keys that can be used for link layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client. Forgoing authentication increases the chance of man-in-the-middle and other types of attacks that can compromis
