Subject: Re: [Emu] EMU Charter revision

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Feb 2008 11:54:06 -0800

I also do NOT approve of the current charter revision, for several reasons:

a.  The Charter text contains statements that are no longer true.  For example:
"Most of these methods are proprietary methods and only a few methods 
are documented in RFCs."

The following EAP methods are now documented in RFCs:

EAP-TLS (RFC 2716)
EAP-SIM (RFC 4186)
EAP-AKA (RFC 4187)
EAP-PAX (RFC 4746)
EAP-SAKE (RFC 4763)
EAP-PSK (RFC 4764)
EAP-POTP (RFC 4793)
EAP-FAST (RFC 4851)
EAP-IKEv2 (RFC 5106)

9 methods claiming to satify RFC 4017 critieria is more than a "few". 

b. The Charter requires support for Channel Bindings without doing the
preparatory work to define how Channel Bindings works.  Either the
requirement should be removed, or a work item should be added to 
better define the approach to Channel Bindings. 

c. The text on tunnel methods does not provide enough guidance to avoid
potentially fruitless arguments.  So far, the EMU WG has not been able
to come to consensus on selection of one of the existing tunneling
protocols, and efforts to design "yet another" tunneling protocol 
haven't gotten very far either.  I'd like to see more specific 
language that would make it clear that work on improving existing
tunneling protocols is within scope, and also that the EMU WG,
if it cannot come to consensus on a single protocol, can proceed to 
work on one or more protocols with significant support.  

d. Password-based methods.  While I can understand the desire to limit the
number of charter items, I do agree with Dan that work on weak-password
methods is important.  With some of the IPR obstacles likely to fall by
the wayside in coming years, it is time for the IETF to re-visit its policy
on inclusion of "zero knowledge" algorithms within standards track documents. 
Dan Harkins said:

" Hi Joe,

  I do NOT approve of the current charter revision, specifically the
change that says the password-based method can only be via the
tunneled method. I do approve of the inclusion of tunneled methods
in the charter though and would be willing to contribute as a
reviewer.

  regards,

  Dan."
On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote:
> The response to the charter revision has been underwhelming.  I am a bit
> concerned that we do not have enough participation to complete the
> tunnel method work (most of the recent discussion has been about other
> methods).
>
> I would like to get an idea of the number working group members that
> approve of working on the tunnel method items and are able to
> participate in the development of requirements and specifications as
> contributors and/or reviewers.
>
> Please respond to this message and state whether you approve of the
> current charter revision and what capacity you would be willing to
> contribute towards tunneled method development: contributor, reviewer or
> not able to contribute.
>
> I have submitted an internet draft attempt at an outline of requirements
> for tunneled methods
> (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
> txt) that I hope can provided a starting point for discussions on the
> list and in the Philadelphia meeting.
>
> Thanks,
>
> Joe
_______________________________________________
Emu mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/emu

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 22 Feb 2008 15:34:56 +0100

Hi Bernard,
 
a question your excitment regarding strong password based EAP method. 
 
Why do you think they are useful? There are other ways (and they are
deployed already) that can accomplish the same result without going
along the SRP & co track. 
Is it because you expect performance improvements or because the
crypto-mechanisms look nicer? 
 
I cannot quite understand the motivation. 
 
Ciao
Hannes

________________________________

	Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von ext Bernard Aboba
	Gesendet: Donnerstag, 21. Februar 2008 21:54
	An: [email-masked]
	Betreff: Re: [Emu] EMU Charter revision

	I also do NOT approve of the current charter revision, for
several reasons:
	
	a.  The Charter text contains statements that are no longer
true.  For example:
	
	"Most of these methods are proprietary methods and only a few
methods 
	are documented in RFCs."

	EAP-TLS (RFC 2716)
	EAP-SIM (RFC 4186)
	EAP-AKA (RFC 4187)
	EAP-PAX (RFC 4746)
	EAP-SAKE (RFC 4763)
	EAP-PSK (RFC 4764)
	EAP-POTP (RFC 4793)
	EAP-FAST (RFC 4851)
	EAP-IKEv2 (RFC 5106)
	
	9 methods claiming to satify RFC 4017 critieria is more than a
"few". 
	
	b. The Charter requires support for Channel Bindings without
doing the
	preparatory work to define how Channel Bindings works.  Either
the
	requirement should be removed, or a work item should be added to

	c. The text on tunnel methods does not provide enough guidance
to avoid
	potentially fruitless arguments.  So far, the EMU WG has not
been able
	to come to consensus on selection of one of the existing
tunneling
	protocols, and efforts to design "yet another" tunneling
protocol 
	haven't gotten very far either.  I'd like to see more specific 
	language that would make it clear that work on improving
existing
	tunneling protocols is within scope, and also that the EMU WG,
	if it cannot come to consensus on a single protocol, can proceed
to 
	work on one or more protocols with significant support.  
	
	d. Password-based methods.  While I can understand the desire to
limit the
	number of charter items, I do agree with Dan that work on
weak-password
	methods is important.  With some of the IPR obstacles likely to
fall by
	the wayside in coming years, it is time for the IETF to re-visit
its policy
	on inclusion of "zero knowledge" algorithms within standards
track documents. 
	Dan Harkins said:
	
	" Hi Joe,

	  I do NOT approve of the current charter revision, specifically
the
	change that says the password-based method can only be via the
	tunneled method. I do approve of the inclusion of tunneled
methods
	in the charter though and would be willing to contribute as a
	reviewer.
	
	  regards,
	
	  Dan."
	On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey)

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 22 Feb 2008 10:22:19 -0800 (PST)

Hi Hannes,

  What are these methods? And is their security completely based
on an assumption that the one deploying this method is following
some strict regime (e.g. no weak passwords)?

  regards,

  Dan.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 21:14:07 +0200

Hi Dan,

you are asking me which EAP methods support weak passwords?

If so, here are a few examples:
* TTLS
* PEAP
* EAP-PAX
* EAP-FAST
* EAP-IKEv2

Please note that I am not against doing the work; I would just like to 
understand what the main motivation is.

Ciao
Hannes

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 22 Feb 2008 12:32:49 -0800 (PST)

Hi Hannes,

  The first 4 of those require a certificate (well, PAX doesn't but as
it says in its Security Considerations if you don't use one then it's
open to dictionary attack) and in some situations it is desirable to not
have one.

  From personal experience I have run into scores and scores of
systems that get deployed using self-signed certificates and then
something that is not resistant to dictionary attack as the client-side
authentication method. So the end result is a system that does not
have the properties that the protocols it implements claim it should
have. The fact that "verify server certificate" is an option underscores
this problem.

  I think it is very valuable to have protocols that are secure in the
presence of poor operational deployment. We all know things will get
deployed in the most expeditious manner possible so having protocols
that remain secure in the presence of weak passwords or self-signed
certificates or whathaveyou is A Good Thing (tm). They are robust, not
fragile.

  About EAP-IKEv2.... Please don't take offense but I think it is
an abomination. We can have EAP-IKEv2 with AAA1 authenticating with a
certificate and the client doing EAP for client-side authentication
which gets passed to AAA2 which does TTLS (or FAST or PEAP) and
authenticates with its own certificate and the client authentication
is...EAP! Which gets passed to AAA3 where EAP-MSCHAPv2 is done and
AAA4 is asked if some particular username/password is correct or not.
Is that username the same as the one provided in EAP-IKEv2 or in TTLS?
Who knows! But some server somewhere says that a single username/password
combination is correct and that's just supposed to be OK. Note that if
a TLS ciphersuite to do EAP for client-side authentication goes past
I-D stage then this can be extended several more steps, involving AAA5
and AAA6, without even duplicating EAP methods anywhere.

  regards,

  Dan.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Feb 2008 13:23:33 -0800

"Zero knowledge" is definitely crypto-intensive.  For example, to get both privacy and strong password protection, at least two DHs are required. 

However, there are circumstances where server-side certificates aren't acceptable.  Even in today, many/(most?) EAP deployments do not involve certificates (e.g. LEAP, FAST).   Even if "zero knowledge" isn't used on an ongoing basis (out of concern for load, for example), it still can be useful for initial provisioning.  For example, EAP FAST provisioning is vulnerable to man-in-the-middle attack or dictionary attack, which could be removed with use of "zero knowledge" algorithms.    

Subject: AW: [Emu] EMU Charter revision
Date: Fri, 22 Feb 2008 15:34:56 +0100
From: [email-masked]
To: [email-masked]; [email-masked]

Hi Bernard,
 
a question your excitment regarding strong password based EAP 
method. 
 
Why do you think they are useful? There are other ways (and they 
are deployed already) that can accomplish the same result without going 
along the SRP & co track. 
Is it because you expect performance improvements or because the 
crypto-mechanisms look nicer? 

Ciao
Hannes

  Von: [email-masked] 
  [mailto:[email-masked]] Im Auftrag von ext Bernard 
  Aboba
Gesendet: Donnerstag, 21. Februar 2008 21:54
An: 
  [email-masked]
Betreff: Re: [Emu] EMU Charter 
  revision

  I also do NOT approve of the current charter revision, for several 
  reasons:

a.  The Charter text contains statements that are no 
  longer true.  For example:
"Most of these methods are proprietary methods and only a few methods 
are documented in RFCs."

EAP-TLS (RFC 2716)
EAP-SIM (RFC 4186)
EAP-AKA (RFC 4187)
EAP-PAX (RFC 4746)
EAP-SAKE (RFC 4763)
EAP-PSK (RFC 4764)
EAP-POTP (RFC 4793)
EAP-FAST (RFC 4851)
EAP-IKEv2 (RFC 5106)

Dan 
  Harkins said:

" Hi Joe,

  regards,

  Dan."

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Feb 2008 11:19:48 +0200

Hi Bernard,

Bernard Aboba wrote:
> However, there are circumstances where server-side certificates aren't acceptable.  Even in today, many/(most?) EAP deployments do not involve certificates (e.g. LEAP, FAST). 
The good thing is that the approach would work with even a self-signed 
certificate since there is a big difference between the certificates 
used in the Web environment and for network access. In the former case 
you want to make sure that the browser with any webserver on the 
Internet. This is an any-to-any relationship. For network access you 
have a many-to-one relationship.

>   Even if "zero knowledge" isn't used on an ongoing basis (out of concern for load, for example), it still can be useful for initial provisioning.
Provisioning the initial security is an entirely different problem. EAP 
is the wrong way todo that.
See for example the interesting work done in the KEYPROV working group.

>   For example, EAP FAST provisioning is vulnerable to man-in-the-middle attack or dictionary attack, which could be removed with use of "zero knowledge" algorithms.    
>   
Need to look at this aspect of the draft again.

Ciao
Hannes

> ------------------------------------------------------------------------
>

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 23 Feb 2008 02:38:33 -0800 (PST)

Hi Hannes,

  What you're saying is not that it "would work" but that it "could work".
If it's deployed correctly. And if there's some step that each and every
client MUST go through to accept a certificate. So _if_ _every_ client
goes through this step than it _can_ work. If, for some reason, this
strict regime is not followed then it doesn't work.

  The issue isn't whether it can be made secure provided some series
of steps are religiously followed. It's whether it will be secure even
if those steps are not religiously followed.

  Dan.

On Sat, February 23, 2008 1:19 am, Hannes Tschofenig wrote:
> Hi Bernard,
>
> Bernard Aboba wrote:
>> "Zero knowledge" is definitely crypto-intensive.  For example, to get
>> both privacy and strong password protection, at least two DHs are
>> required.
>>
>> However, there are circumstances where server-side certificates aren't
>> acceptable.  Even in today, many/(most?) EAP deployments do not involve
>> certificates (e.g. LEAP, FAST).
>>   Even if "zero knowledge" isn't used on an ongoing basis (out of
>> concern for load, for example), it still can be useful for initial
>> provisioning.
>>   For example, EAP FAST provisioning is vulnerable to man-in-the-middle
>> attack or dictionary attack, which could be removed with use of "zero
>> knowledge" algorithms.
>>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Feb 2008 10:57:31 -0800

In practice it is difficult to securely support self-signed certificates.  There are several issues involved:

a. Vulnerability to man-in-the-middle attack on initial provisioning.  For wireless networks, this is a significant risk, more so than with protocols like SSH, where initial contact might occur over a wired network. 

b. Potential for affecting other applications.  Self-signed certificates, if trusted for a given use, must not be used as trust anchors for other uses.  This can require significant additional work to make sure that trust is properly isolated. 

For these reasons, I do not believe that EAP methods relying on self-signed certificates satisfy the requirements of RFC 4017.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Feb 2008 15:23:15 -0500

I have an opinion about Channel Binding.  Based on discussion to
create RFC 4962 and draft-ietf-hokey-key-mgt, I came to believe that
EAP method is not the right tool to solve the Channel Binding problem
even if RFC 3748 has Channel Binding in its list of security claims on
EAP method.  This is because EAP methods are based on two-party
keying, while the Channel Binding problem essentially came from
separation of EAP authenticator and EAP server.  I think Channel
Binding is best solved using a three-party key distribution protocol
e.g., by re-designing EAP to be a 3-party protocol, but that is not
what EMU WG is supposed to do, either.

Said that I suggest removing Channel Binding support from the EMU
charter.

Yoshihiro Ohba

---

From: "Katrin Höper" <[email-masked]>
Date: Wed, 27 Feb 2008 14:32:46 -0500

Yoshi,

I disagree. I think channel binding can and should be be provided by EAP
methods.

An approach that can be used to add channel binding to any EAP method that
supports mutual authentication and key establishment is outlined in:

http://tools.ietf.org/id/draft-clancy-emu-aaapay-00.txt
and
http://tools.ietf.org/id/draft-clancy-emu-chbind-00.txt

Yes, some additional system requirements that must be ensured outside of EAP
seem to be necessary. But I believe that would be always the case, no matter
would protocol you would use to provide channel binding.

The drafts will be presented at the meeting in Philadelphia.

Katrin

On Sun, Feb 24, 2008 at 3:23 PM, Yoshihiro Ohba <[email-masked]>
wrote:

> > > (
> http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu