Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04

From: Yaron Sheffer <[email-masked]>
Date: Thu, 4 Mar 2010 08:16:00 +0200

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)" <[email-masked]>
> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> To: "Dan Harkins" <[email-masked]>,	"Hoeper Katrin-QWKN37"
> 	<[email-masked]>
> Cc: [email-masked]
> Message-ID:
> 	<AC1CFD94F59A264488DC2BEC3E890DE509BD3EBA@xmb-sjc-
> 225.amer.cisco.com>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi Dan,
> 
> The document currently states anonymous cipher suites MUST NOT be
> mandatory to implement for the tunnel method.  I think the is the
> appropriate stance for the document to take for the base tunnel method.
> I also do not think this prevents a follow-on specification defining
> how
> to use anonymous tunnel securely.
> 
> Cheers,
> 
> Joe
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Mar 2010 07:47:22 +0100

> 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 d…

  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.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 4 Mar 2010 09:05:10 +0200

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:[email-masked]]
> Sent: Thursday, March 04, 2010 8:47
> To: Yaron Sheffer
> Cc: [email-masked]
> > 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?
> 
> Scanned by Check Point Total Security Gateway.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Mar 2010 08:57:05 +0100

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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 4 Mar 2010 07:11:17 -0800

> 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
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 4 Mar 2010 07:11:31 -0800

Hi Yaron,

The existing text is just about restricting the mandatory to implement
cipher suites.  Are you OK with the text?   

Thanks,

Joe

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yaron Sheffer
> Sent: Wednesday, March 03, 2010 11:05 PM
> To: Alan DeKok
> Cc: [email-masked]
> 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.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 4 Mar 2010 18:00:47 +0200

Hi Joe,

Yes, I am OK with the text.

Thanks,
	Yaron

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Thursday, March 04, 2010 17:12
> To: Yaron Sheffer; Alan DeKok
> Cc: [email-masked]
> Subject: RE: [Emu] review of draft-ietf-emu-eaptunnel-req-04
> 
> Hi Yaron,
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 4 Mar 2010 08:49:38 -0800 (PST)

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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 4 Mar 2010 11:10:29 -0800

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

> From: Dan Harkins [mailto:[email-masked]]
> Sent: Thursday, March 04, 2010 8:50 AM
> To: Joseph Salowey (jsalowey)
> Cc: Yaron Sheffer; [email-masked]

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Thu, 4 Mar 2010 16:30:08 -0500

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

> Joseph Salowey (jsalowey)
> Sent: Thursday, March 04, 2010 1:10 PM
> To: Dan Harkins
> Cc: [email-masked]; Yaron Sheffer
> > installed certificate (and I know EAP-FAST has this as an option
too)
> but
> > > for the base method.  I agree that using anonymous cipher suites
in
> > > are other ways provisioning can be achieved with or without the
use
> of

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 4 Mar 2010 14:29:32 -0800 (PST)

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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Thu, 4 Mar 2010 18:03:26 -0500

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

> Sent: Thursday, March 04, 2010 4:30 PM
> To: Hoeper Katrin-QWKN37
> Cc: Joseph Salowey; Dan Harkins; [email-masked]; Yaron Sheffer
> >> >      provisioning.  When a peer has authenticated with EAP, this
is
> > a
> >> >      convenient time to distribute credentials to that peer that
may
> >> be
> >> > try to tell some guy deploying product that no he can't do what
he
> >> wants
> >> > 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
> >> > >> important for many types of deployments. Does the document
allow
> > an
> >> > > way Dan proposes can be used in a provisioning mechanism,
however
> >> there
> >> > >> Dan, I suspect that for this specific use case (one time use,
no
> >> need
> >> > >> > 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.