Subject: Re: [Emu] EMU charter revision

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Apr 2008 15:12:43 +0300

Gene Chang said:

> Dan,
> I am not sure I am able to clearly understand the end result you seek.
> It seems there is a clear consensus for a tunneled method. Are you
> pushing for the addition of a tunneled method?
>
> Ok... I am easily baited. What would you like to see to achieve more
> than a snail race? I am assuming we both believe the term "snail race"
> is a pejorative. Thus I ask you, how do we do better?
>
> I clearly hear your comment that there have been a paucity of  
> comments,
> if nothing else, simply to affirm we are on track. I agree with the
> proposed charter. I am open to a discussion to add a non-tunneled  
> method
> if there is sufficient demand. A non-tunneled method does not seem to
> promise enough features for the use cases that interest me.
>
> Gene

Hi Gene,

You did not specify what the uses that interest you are, and I don't  
know about the use cases that interest Dan either, but I can speak for  
the use cases that interest me.

EAP has been used in several cases as a magic way to use legacy  
credentials in protocols. I'll cite three examples:

1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple, Cisco and  
others, where an EAP method is used to authenticate the user.
2. IKEv2 (RFC 4306) where EAP is used to magically authenticate the  
initiator using non-cert and non-PSK credentials.
3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate the  
user.

In all three cases EAP is used by a protocol inside an encrypted  
tunnel, where the server, which is either trusted by the authenticator  
or co-located with it is already authenticated by a certificate or  
PSK.  IMO EAP was used in all cases an some magical way of making  
passwords into a secure authentication mechanism.  The problem is that  
there really is no publicly available EAP method for passwords.

Tunneled methods don't really make sense here.  There's no benefit in  
putting a TLS tunnel inside an IKEv2 exchange just to pass the  
password. Something like EAP-SRP would be great if it (a) existed and  
(b) didn't have all that IPR baggage. The method that Dan is proposing  
would also be beneficial here, if we could get a WG behind it so we  
can get some solid security review.  Instead, what implementors are  
doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements  
for any of the above protocols.

Yoav

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Gene Chang (genchang)" <[email-masked]>
Date: Mon, 28 Apr 2008 08:23:42 -0400

Yoav,

I ask for some latitude in my choice of words to describe some of the
use cases that interest me. It feels to me (possibly its must me being
naive) that we are tip-toeing around the dual use of some EAP methods to
support some interesting use cases. These use cases are out of scope for
EMU.

Explicitly I am interested in both authentication which is in scope for
EMU and NAC which is out of scope. The tunneled EAP methods, esp.
EAP-FAST and EAP-TTLS, are used for both purposes. We can easily create
methods that would only meet the needs of authentication and useless for
NAC. I am not interested in spending efforts to such an outcome.

Gene

------------------------------------------------------------------------
----
Eugene Chang (genchang)
Cisco Systems

Office:   603-559-2978
Mobile:  781-799-0233

Skype:  gene02421

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Monday, April 28, 2008 8:13 AM
To: [email-masked]
Subject: Re: [Emu] EMU charter revision

Gene Chang said:

	Dan,
	I am not sure I am able to clearly understand the end result you
seek.
	It seems there is a clear consensus for a tunneled method. Are
you
	pushing for the addition of a tunneled method? 
	
	Ok... I am easily baited. What would you like to see to achieve
more
	than a snail race? I am assuming we both believe the term "snail
race"
	is a pejorative. Thus I ask you, how do we do better?
	
	I clearly hear your comment that there have been a paucity of
comments,
	if nothing else, simply to affirm we are on track. I agree with
the
	proposed charter. I am open to a discussion to add a
non-tunneled method
	if there is sufficient demand. A non-tunneled method does not
seem to
	promise enough features for the use cases that interest me.
	
	Gene

Hi Gene,

In all three cases EAP is used by a protocol inside an encrypted tunnel,
where the server, which is either trusted by the authenticator or
co-located with it is already authenticated by a certificate or PSK.
IMO EAP was used in all cases an some magical way of making passwords
into a secure authentication mechanism.  The problem is that there
really is no publicly available EAP method for passwords.

Tunneled methods don't really make sense here.  There's no benefit in
putting a TLS tunnel inside an IKEv2 exchange just to pass the password.
Something like EAP-SRP would be great if it (a) existed and (b) didn't
have all that IPR baggage. The method that Dan is proposing would also
be beneficial here, if we could get a WG behind it so we can get some
solid security review.  Instead, what implementors are doing is EAP-MD5
or EAP-GTC, which don't quite meet the requirements for any of the above
protocols.

Yoav

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Mon, 28 Apr 2008 11:10:17 -0400

Yoav:
 
I thought we had clear consensus in IETF 71 WG meeting and instructed by
the AD that while Dan's proposal is an interesting one, but it doesn't
work with the legacy password databases and thus out-of the scope of the
charter. Until we have the proof of security analysis and clear of IPR
issues, the WG is going to work on the tunnel method. I think this is
the use case, legacy password database, the working group is currently
working on and Gene is talking about
 
Can you also explain why in the three use case you cited, EAP-GTC or MD5
doesn't meet the requirements, as they are all running inside an
authenticated and encrypted tunnel?

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Yoav Nir
	Sent: Monday, April 28, 2008 8:13 AM
	To: [email-masked]
	Subject: Re: [Emu] EMU charter revision

	Gene Chang said: 

		Dan,
		I am not sure I am able to clearly understand the end
result you seek.
		It seems there is a clear consensus for a tunneled
method. Are you
		pushing for the addition of a tunneled method? 
		
		Ok... I am easily baited. What would you like to see to
achieve more
		than a snail race? I am assuming we both believe the
term "snail race"
		is a pejorative. Thus I ask you, how do we do better?
		
		I clearly hear your comment that there have been a
paucity of comments,
		if nothing else, simply to affirm we are on track. I
agree with the
		proposed charter. I am open to a discussion to add a
non-tunneled method
		if there is sufficient demand. A non-tunneled method
does not seem to
		promise enough features for the use cases that interest
me.
		
		Gene

	Hi Gene,

	You did not specify what the uses that interest you are, and I
don't know about the use cases that interest Dan either, but I can speak
for the use cases that interest me.

	1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple,
Cisco and others, where an EAP method is used to authenticate the user.
	2. IKEv2 (RFC 4306) where EAP is used to magically authenticate
the initiator using non-cert and non-PSK credentials.
	3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate
the user.

or co-located with it is already authenticated by a certificate or PSK.

	Tunneled methods don't really make sense here.  There's no
benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass
the password. Something like EAP-SRP would be great if it (a) existed
and (b) didn't have all that IPR baggage. The method that Dan is
proposing would also be beneficial here, if we could get a WG behind it
so we can get some solid security review.  Instead, what implementors
are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements
for any of the above protocols.

	Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Apr 2008 09:45:08 -0700 (PDT)

Hold on a second there Hao. A security proof was never a requirement.
I'm not aware of any other IETF protocols that required security proofs
or even have security proofs. There is no formal proof required of the
tunneled methods and I think it would be very difficult to do one.

  One of the problems with the tunneled solution is the "consistency
principle" described in Hugo Krawczyk's SIGMA paper. The tunneled methods
violate that security requirement. And the fact that these things can
be repeatedly tunneled ad nauseum amplifies that violation.

  A use case? Surely you have noticed the friction between usability and
security. Security needs bootstrapping of some sort and typically that
is problematic for many people especially when they need to bootstrap a
large number of distinct security associations. So they cut corners.

  How are these corners cut? "Do not verify server certificate". That's
why that little check box exists. Because people don't want to enroll
everybody/everything into a CA. So they use a self-signed certificate
and check the "Do not verify server certificate" check box. And then
they send a password over this "encrypted tunnel".

  So the use case is robust security that cannot be provisioned insecurely.
It's scalable and doesn't require the cutting of corners by administrators
who are too busy (or frankly lazy) to do it the Correct Way. I have used
the "it's their network and if they aren't so concerned about security then
who am I to force a workload on them" comments in the past but it really is
disingenuous.

  There are frightfully many deployments of password-authentication-through-
encrypted-TLS-tunnel that use self-signed certificates and then something
analogous to PAP. And they are done that way because there isn't a viable
standard alternative. That is the use case for EAP-pwd. Oh, and it can
satisfy the "consistency principle" too. :-)

  Dan.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Mon, 28 Apr 2008 13:32:14 -0400

Dan:

Now you have changed to argue that tunnel method is not the right
solution for the use case EMU is targeted on, instead of arguing your
proposed password should be included as addition to the tunnel method. I
thought working on and standardizing the tunnel method is the WG
consensus for few IETF meetings now, are you going to challenge that
now? Maybe this also contributes to the "snail race" of tunnel method.

As for the password method you proposed, I was at the last IETF meeting
and you can also verify from he meeting minutes. The consensus is to
have more security reviews and the IPR analysis. Also, since the use
case it targeted maybe more broader than the EMU WG, it was suggested to
bring up in SAAG as well, as multiple WGs can benefit from it. But the
direction from the AD is to finish existing work first.

Why are we keeping bring this up?

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Monday, April 28, 2008 12:45 PM
> To: Hao Zhou (hzhou)
> Cc: Yoav Nir; [email-masked]
> I'm not aware of any other IETF protocols that required 
> security proofs or even have security proofs. There is no 
> formal proof required of the tunneled methods and I think it 
> would be very difficult to do one.
> 
>   One of the problems with the tunneled solution is the 
> "consistency principle" described in Hugo Krawczyk's SIGMA 
> paper. The tunneled methods violate that security 
> requirement. And the fact that these things can be repeatedly 
> tunneled ad nauseum amplifies that violation.
> 
>   A use case? Surely you have noticed the friction between 
> usability and security. Security needs bootstrapping of some 
> sort and typically that is problematic for many people 
> especially when they need to bootstrap a large number of 
> distinct security associations. So they cut corners.
> 
>   How are these corners cut? "Do not verify server 
> certificate". That's why that little check box exists. 
> Because people don't want to enroll everybody/everything into 
> a CA. So they use a self-signed certificate and check the "Do 
> not verify server certificate" check box. And then they send 
> a password over this "encrypted tunnel".
> 
> It's scalable and doesn't require the cutting of corners by 
> administrators who are too busy (or frankly lazy) to do it 
> the Correct Way. I have used the "it's their network and if 
> they aren't so concerned about security then who am I to 
> force a workload on them" comments in the past but it really 
> is disingenuous.
> 
>   There are frightfully many deployments of 
> password-authentication-through- encrypted-TLS-tunnel that 
> use self-signed certificates and then something analogous to 
> PAP. And they are done that way because there isn't a viable 
> standard alternative. That is the use case for EAP-pwd. Oh, 
> and it can satisfy the "consistency principle" too. :-)
> 
>   Dan.
> 
> > I thought we had clear consensus in IETF 71 WG meeting and 
> instructed 
> > by the AD that while Dan's proposal is an interesting one, but it 
> > doesn't work with the legacy password databases and thus out-of the 
> > scope of the charter. Until we have the proof of security 
> analysis and 
> > clear of IPR issues, the WG is going to work on the tunnel 
> method. I 
> > think this is the use case, legacy password database, the working 
> > group is currently working on and Gene is talking about
> >
> > Can you also explain why in the three use case you cited, 
> EAP-GTC or 
> > MD5 doesn't meet the requirements, as they are all running 
> inside an 
> > 	From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> > Yoav Nir
> > 		if there is sufficient demand. A non-tunneled 
> method does not seem 
> > to
> > 	1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, 
> Apple, Cisco 
> > and others, where an EAP method is used to authenticate the user.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 28 Apr 2008 11:35:37 -0700 (PDT)

Hao,

> now? Maybe this also contributes to the "snail race" of tunnel method.

  It is the consensus. I'm not challenging consensus, just answering
a question. "Do you approve of this charter?" Well, no I don't. I was
told by the ADs that EAP-pwd is outside the current charter. Fine. We
can't work on it but that doesn't mean I approve of the charter; I don't,
for that very reason. If I'm asked again I'll give the same answer again.

  Don't blame me for the pace of the work in this WG. I don't have a stake
in the outcome of the only thing we're allowed to work on. And I don't
believe a quarterly email saying "I don't approve" (of the charter) is
enough to put those who do have a stake in the outcome off their work
schedules.

> direction from the AD is to finish existing work first.

  Yes, I remember. But you said, "Until we have a proof...we will work
on the tunneled method." IPR issues, yes that will probably hold things
up. But a proof, no. No proof is required prior to adoption as a work item.
If it was then where's the security proof for either tunneled method?

  The real thing holding up adoption of EAP-pwd as a work item is finishing
work on the tunneled method. Which wouldn't be such a bad thing if we
were further along towards that goal after Philly than we were after
Vancouver and from the looks of it we won't be any further after Dublin
than we were after Vancouver. :-(

> Why are we keeping bring this up?

  You asked why are tunneled GTC and tunneled MD5 not OK; you asked what
is the use case for EAP-pwd. I answered both: consistency principle and a
need for robustness, respectively.

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 28 Apr 2008 11:41:33 -0700

Hi Yoav,

You bring up an interesting point in discussing the need for EAP
password based authentication within other protected protocols.  If this
is targeted at working with legacy databases then I think it can be
accommodated under the current charter.  An EAP protected tunnel is
required for some deployments, however perhaps the tunneled password
protocol can be designed to be used in other cases (IKEv2, TLS, etc.) if
the group wants to take this direction.  What do you see lacking in
something like EAP-GTC?

Cheers,

Joe 

> Sent: Monday, April 28, 2008 5:13 AM
> To: [email-masked]
> You did not specify what the uses that interest you are, and 
> I don't know about the use cases that interest Dan either, 
> but I can speak for the use cases that interest me.
> 
> 
> EAP has been used in several cases as a magic way to use 
> legacy credentials in protocols. I'll cite three examples:
> 
> 
> 2. IKEv2 (RFC 4306) where EAP is used to magically 
> authenticate the initiator using non-cert and non-PSK credentials.
> 3. TEE (draft-nir-tls-eap-03) where EAP is used to 
> authenticate the user.
> 
> 
> In all three cases EAP is used by a protocol inside an 
> encrypted tunnel, where the server, which is either trusted 
> by the authenticator or co-located with it is already 
> authenticated by a certificate or PSK.  IMO EAP was used in 
> all cases an some magical way of making passwords into a 
> secure authentication mechanism.  The problem is that there 
> benefit in putting a TLS tunnel inside an IKEv2 exchange just 
> to pass the password. Something like EAP-SRP would be great 
> if it (a) existed and (b) didn't have all that IPR baggage. 
> The method that Dan is proposing would also be beneficial 
> here, if we could get a WG behind it so we can get some solid 
> security review.  Instead, what implementors are doing is 
> EAP-MD5 or EAP-GTC, which don't quite meet the requirements

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Apr 2008 10:11:01 +0300

Hi Joe,

I don't see much wrong with EAP-GTC, and I may end up using it for  
legacy RADIUS support, But there are two arguments against using it.

1. The typical deployment of an IKE gateway is that there's a RADIUS  
or LDAP server somewhere in the internal network or even on another  
network in the case of a branch office gateway. EAP is usually  
forwarded to that server. If the forwarded payload is GTC, it's  
something malicious (perhaps on the internal network) might sniff it  
and get the password.

2. There is a threat scenario described in http://eprint.iacr.org/2002/163 
. The idea is that a client that does EAP-GTC will do it both in a  
secure tunnel (such as in IKEv2) and outside of a secure tunnel (such  
as 802.1x). Someone sniffing the 802.1x will be able to acquire the  
password.  This sounds simplistic to me, but more realistically, if  
IKEv2 (or even more so - TLS) is authenticated with a password, it may  
be tempting, as Dan pointed out, to uncheck the "verify server  
certificate" because "we're authenticating with a certificate".

IOW, the user is actually authenticating to the RADIUS server, which  
tells the gateway that the user is authenticated. Since the gateway  
can't authenticate the user on its own, it makes sense that the client  
can't authenticate the gateway on its own. The RADIUS server sends the  
MSK to the gateway and the gateway sends a PoP to the client, and that  
is the proof the client has that the gateway is "authentic". But for  
this to work, you need an EAP method that (1) generates keys, and (2)  
mutually authenticates the client and server.  These are required in  
the IKEv2 RFC.

Tunneling a method like EAP-GTC gives you the keys and the mutual  
authentication but it requires that the client be able to verify the  
server certificate, and it requires that the tunneling go all the way  
to the server, rather than GTC going to the server, while the tunnel  
terminates at the gateway.  It still takes a lot of round trips to get  
it to work, and a non-tunneled method like EAP-SRP or EAP-pwd would  
probably be better suited.

Yoav

On Apr 28, 2008, at 9:41 PM, Joseph Salowey (jsalowey) wrote:

> Scanned by Check Point Total Security Gateway.
>

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 30 Apr 2008 12:34:02 -0400

Dan wrote:

>   The real thing holding up adoption of EAP-pwd as a work 
> item is finishing work on the tunneled method. Which wouldn't 
> be such a bad thing if we were further along towards that 
> goal after Philly than we were after Vancouver and from the 
> looks of it we won't be any further after Dublin than we were 
> after Vancouver. :-(

I don't think tunnel method is the real thing holding up the EAP-pw as a
work item, so stop attacking the tunnel method or hurry it into some
kind of "sword fight." As others pointed out, EAP-pw might be quite
useful for multiple WGs and should be bring to SAAG. But security review
and IPR analysis need to be done before any WG is willing to take that
work, I think.  

> Sent: Monday, April 28, 2008 2:36 PM
> To: Hao Zhou (hzhou)
> Cc: Dan Harkins; Yoav Nir; [email-masked]
> Subject: RE: [Emu] EMU charter revision
> 
> 
>   Hao,
> 
> > proposed password should be included as addition to the 
> tunnel method. 
> > I thought working on and standardizing the tunnel method is the WG 
>   It is the consensus. I'm not challenging consensus, just 
> answering a question. "Do you approve of this charter?" Well, 
> no I don't. I was told by the ADs that EAP-pwd is outside the 
> current charter. Fine. We can't work on it but that doesn't 
> mean I approve of the charter; I don't, for that very reason. 
> If I'm asked again I'll give the same answer again.
> 
>   Don't blame me for the pace of the work in this WG. I don't 
> have a stake in the outcome of the only thing we're allowed 
> to work on. And I don't believe a quarterly email saying "I 
> don't approve" (of the charter) is enough to put those who do 
> have a stake in the outcome off their work schedules.
> 
> > As for the password method you proposed, I was at the last IETF 
> > meeting and you can also verify from he meeting minutes. 
> The consensus 
> > is to have more security reviews and the IPR analysis. 
> Also, since the 
> > use case it targeted maybe more broader than the EMU WG, it was 
> > suggested to bring up in SAAG as well, as multiple WGs can benefit 
> > from it. But the direction from the AD is to finish 
> existing work first.
> 
>   Yes, I remember. But you said, "Until we have a proof...we 
> will work on the tunneled method." IPR issues, yes that will 
> probably hold things up. But a proof, no. No proof is 
> required prior to adoption as a work item.
>   The real thing holding up adoption of EAP-pwd as a work 
> item is finishing work on the tunneled method. Which wouldn't 
> be such a bad thing if we were further along towards that 
> goal after Philly than we were after Vancouver and from the 
> looks of it we won't be any further after Dublin than we were 
> after Vancouver. :-(
> 
>   You asked why are tunneled GTC and tunneled MD5 not OK; you 
> asked what is the use case for EAP-pwd. I answered both: 
> consistency principle and a need for robustness, respectively.
> 
>   Dan.
> 
> >> I'm not aware of any other IETF protocols that required security 
> >> proofs or even have security proofs. There is no formal proof 
> >> required of the tunneled methods and I think it would be very 
> >> difficult to do one.
> >>
> "consistency 
> >> principle" described in Hugo Krawczyk's SIGMA paper. The tunneled 
> >> methods violate that security requirement. And the fact that these 
> >> things can be repeatedly tunneled ad nauseum amplifies that 
> >> violation.
> >>
> usability 
> >> and security. Security needs bootstrapping of some sort 
> and typically 
> >> that is problematic for many people especially when they need to 
> >> bootstrap a large number of distinct security 
> associations. So they 
> >> cut corners.
> >>
> >>   How are these corners cut? "Do not verify server certificate". 
> >> That's why that little check box exists.
> >> Because people don't want to enroll everybody/everything 
> into a CA. 
> >> So they use a self-signed certificate and check the "Do not verify 
> >> server certificate" check box. And then they send a password over 
> >> this "encrypted tunnel".
> >>
> >> administrators who are too busy (or frankly lazy) to do it the 
> >> Correct Way. I have used the "it's their network and if 
> they aren't 
> >> so concerned about security then who am I to force a workload on 
> >> them" comments in the past but it really is disingenuous.
> >>
> >> password-authentication-through- encrypted-TLS-tunnel that use 
> >> self-signed certificates and then something analogous to PAP. And 
> >> they are done that way because there isn't a viable standard 
> >> alternative. That is the use case for EAP-pwd. Oh, and it 
> can satisfy 
> >> the "consistency principle" too. :-)
> >>
> >>   Dan.
> >>
> >> authenticate the
> >> authenticate the
> >> encrypted

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 30 Apr 2008 10:11:42 -0700 (PDT)

Hi Hao,

> and IPR analysis need to be done before any WG is willing to take that

  Let me quote the chairman of this group, Joe Salowey:

    "The message from the ADs in the last meeting was pretty clear in
     that EAP-PWD style mechanisms is not something for the group to
     take on right now.  This does not mean that we cannot take on
     an EAP-PWD style mechanism once we have made progress on the current
     charter items."

And what are the current charter items? GPSK which is getting one last
edit before going off to IETF LC and... the tunneled method! So until "we
have made some progress" on the tunneled method the charter cannot change
to make EAP-pwd in scope of the group.

  Let me mention once more I'm not interested in sword fights. Let's
call it a "beauty contest". And it would be really nice if the contestants
would finish their hair-dos and make-up and get into their evening gowns
and out on the runway so the winner can get crowned.

  Dan.