IETF working group for EAP Methods Update (EMU)

headers Glen Zorn | 1 Sep 2010 04:31

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www.ietf.org/mailman/listinfo/emu

Hoeper Katrin-QWKN37 wrote:
> I will check the current draft for conflicts and, if necessary, propose
> changes.

  I think that the main issue with the draft is that it requires
tunneled methods to allow for password authentication.  Your analysis
paper says that password methods cannot be made resistant to these attacks.

  If that is right, then I don't think there is anything to do in the draft.

  Alan DeKok.

I agree. That's why I was thinking that adding a reference that makes
implementers aware of this problem would be a good idea. Then they can
make an educated decision about whether they want to implement
additional mitigation techniques (i.e. enforce policies) or to not use
password-based inner methods.

> -----Original Message-----
> From: Alan DeKok [mailto:aland <at> deployingradius.com]
> Sent: Wednesday, September 01, 2010 9:34 AM
> To: Hoeper Katrin-QWKN37
> Cc: Glen Zorn; Bernard Aboba; emu <at> ietf.org
> Subject: Re: [Emu] security paper on tunneled authentication
> 
> Hoeper Katrin-QWKN37 wrote:
> > I will check the current draft for conflicts and, if necessary,
propose
> > changes.
> 
>   I think that the main issue with the draft is that it requires
> tunneled methods to allow for password authentication.  Your analysis
> paper says that password methods cannot be made resistant to these
attacks.
> 
>   If that is right, then I don't think there is anything to do in the
> draft.
> 
>   Alan DeKok.

I'd be glad to add a reference.

On 9/1/10 7:40 AM, "Hoeper Katrin-QWKN37" <khoeper <at> motorola.com> wrote:

> I agree. That's why I was thinking that adding a reference that makes
> implementers aware of this problem would be a good idea. Then they can
> make an educated decision about whether they want to implement
> additional mitigation techniques (i.e. enforce policies) or to not use
> password-based inner methods.
> 
> 
>> -----Original Message-----
>> From: Alan DeKok [mailto:aland <at> deployingradius.com]
>> Sent: Wednesday, September 01, 2010 9:34 AM
>> To: Hoeper Katrin-QWKN37
>> Cc: Glen Zorn; Bernard Aboba; emu <at> ietf.org
>> Subject: Re: [Emu] security paper on tunneled authentication
>> 
>> Hoeper Katrin-QWKN37 wrote:
>>> I will check the current draft for conflicts and, if necessary,
> propose
>>> changes.
>> 
>>   I think that the main issue with the draft is that it requires
>> tunneled methods to allow for password authentication.  Your analysis
>> paper says that password methods cannot be made resistant to these
> attacks.
>> 
>>   If that is right, then I don't think there is anything to do in the
>> draft.
>> 
>>   Alan DeKok.
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www.ietf.org/mailman/listinfo/emu

>>>>> "Hoeper" == Hoeper Katrin-QWKN37 <khoeper <at> motorola.com> writes:

    Hoeper> I agree. That's why I was thinking that adding a reference
    Hoeper> that makes implementers aware of this problem would be a
    Hoeper> good idea. Then they can make an educated decision about
    Hoeper> whether they want to implement additional mitigation
    Hoeper> techniques (i.e. enforce policies) or to not use
    Hoeper> password-based inner methods.

Well, we also want to make sure that if you're using a non-password
inner method, then we are not vulnerable to MITM issues.

So, this paper makes it clear that I don't understand some of this stuff
as well as I thought I did.  No surprise there; it's complicated and
this has not been my primary area of focus. so let's see if I can be
educated.

In the part of the world I'm familiar with, we address this problem by
authenticating the identity of the outer tunnel as part of the inner
tunnel.  For example for a TLS-based tunnel we might hash the TLS finish
message into the inner method.  We don't even try to do anything with
plaintext password methods: there's no point you're just kidding
yourself.  We do try and do something with things like SCRAM (think
mschapv2 roughly).  We're typically using the tunnel in order to fight
against dictionary attacks mounted by observers or to provide session
security later.

If I'm reading this paper right that's not what we're doing here in EAP.
We're taking some quantity from the inner method and binding to that?

What's the rationale for that?

The basic reason for this is that EAP methods have a well defined mechanism
to output key material. There hasn't been a mechanism to import data into a
method, channel bindings may change this.

Key generating EAP methods export an MSK.  The MSK is then mixed with key
material extracted from the TLS keying material to form a combined key.
This combined key is then used in a MAC calculation on some data sent within
the tunnel.  The details vary depending on the method.  Typically the MSK
exported from the tunnel method also have the inner method MSK mixed in with
the TLS key material.

There are cases with some EAP methods where data from the TLS tunnel has
been used directly in the inner method.  This behavior causes differences
between the way the method behaves inside the tunnel and outside the tunnel,
which may complicate implementations in many cases.

EAP tunnel methods typically do not try to do any binding with plaintext
basic PAP-like password exchanges.

Hope this helps to clarify things.

Joe

On 9/1/10 10:11 AM, "Sam Hartman" <hartmans-ietf <at> mit.edu> wrote:

> 
> 
> So, this paper makes it clear that I don't understand some of this stuff
> as well as I thought I did.  No surprise there; it's complicated and
> this has not been my primary area of focus. so let's see if I can be
> educated.
> 
> In the part of the world I'm familiar with, we address this problem by
> authenticating the identity of the outer tunnel as part of the inner
> tunnel.  For example for a TLS-based tunnel we might hash the TLS finish
> message into the inner method.  We don't even try to do anything with
> plaintext password methods: there's no point you're just kidding
> yourself.  We do try and do something with things like SCRAM (think
> mschapv2 roughly).  We're typically using the tunnel in order to fight
> against dictionary attacks mounted by observers or to provide session
> security later.
> 
> If I'm reading this paper right that's not what we're doing here in EAP.
> We're taking some quantity from the inner method and binding to that?
> 
> What's the rationale for that?
> _______________________________________________
> Emu mailing list
> Emu <at> ietf.org
> https://www.ietf.org/mailman/listinfo/emu

>>>>> "Joe" == Joe Salowey <jsalowey <at> cisco.com> writes:

    Joe> The basic reason for this is that EAP methods have a well
    Joe> defined mechanism to output key material. There hasn't been a
    Joe> mechanism to import data into a method, channel bindings may
    Joe> change this.

OK, but I'm not sure this quite gets you the properties you want.

As best I can tell:

* The server wants assurance that if an inner method is somehow lifted
  out of a tunneled exchange, the inner method cannot be used alone or
  in a different tunnel.

* The client wants assurance that it's talking to a consistent server so
  that you only end up having to authenticate the server at one level.

Impersonating peers to servers and impersonating servers to peers both
have value to an attacker in different situations.

I think these are the properties you want (And I think the definition in
RFC 3748 is a bit under specified) and I'm not sure how what you've
described gets that.

On 9/1/10 4:56 PM, "Sam Hartman" <hartmans-ietf <at> mit.edu> wrote:

>>>>>> "Joe" == Joe Salowey <jsalowey <at> cisco.com> writes:
> 
>     Joe> The basic reason for this is that EAP methods have a well
>     Joe> defined mechanism to output key material. There hasn't been a
>     Joe> mechanism to import data into a method, channel bindings may
>     Joe> change this.
> 
> OK, but I'm not sure this quite gets you the properties you want.
> 
[Joe] What we wanted from this mechanism was to ensure that the tunnel
endpoints was the same as the inner method endpoints.

> As best I can tell:
> 
> * The server wants assurance that if an inner method is somehow lifted
>   out of a tunneled exchange, the inner method cannot be used alone or
>   in a different tunnel.
> 
[Joe] We didn't want to modify the method.  The purpose was to restrict the
method only to the a particular tunnel type, but we wanted to make sure that
the particular instance of method execution wasn't executed in a different
tunnel or without a tunnel.

> * The client wants assurance that it's talking to a consistent server so
>   that you only end up having to authenticate the server at one level.
> 
[Joe] For most cases the assumption is that the server is authenticated by
the tunnel method. 

> Impersonating peers to servers and impersonating servers to peers both
> have value to an attacker in different situations.
> 
> I think these are the properties you want (And I think the definition in
> RFC 3748 is a bit under specified) and I'm not sure how what you've
> described gets that.

[Joe]  I'm not sure if I understand the properties you describe, so I'm not
sure if they line up with the goals of making sure the tunnel endpoints are
the same as the inner method endpoints.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

3	April 2013
16	March 2013
14	February 2013
2	January 2013
4	November 2012
31	October 2012
11	September 2012
16	July 2012
13	June 2012
20	May 2012
12	April 2012
39	March 2012
18	February 2012
26	January 2012
3	December 2011
6	November 2011
50	October 2011
5	September 2011
30	August 2011
7	July 2011
5	June 2011
44	May 2011
30	April 2011
13	March 2011
10	February 2011
6	January 2011
9	December 2010
4	November 2010
8	October 2010
18	September 2010
5	August 2010
9	July 2010
57	June 2010
9	May 2010
5	April 2010
100	March 2010
2	February 2010
3	January 2010
34	December 2009
4	November 2009
9	October 2009
31	September 2009
106	August 2009
17	July 2009
11	June 2009
12	May 2009
3	April 2009
15	March 2009
74	February 2009
22	January 2009
18	December 2008
16	November 2008
28	October 2008
31	September 2008
35	August 2008
23	July 2008
35	June 2008
9	May 2008
35	April 2008
16	March 2008
30	February 2008
30	January 2008
13	December 2007
8	November 2007
30	October 2007
17	September 2007
53	August 2007
12	July 2007
53	June 2007
12	May 2007
80	April 2007
53	March 2007
56	February 2007
23	January 2007
16	December 2006
80	November 2006
60	October 2006
38	August 2006
23	July 2006
46	June 2006
1	May 2006
4	April 2006
7	March 2006
2	February 2006

Re: security paper on tunneled authentication

Re: security paper on tunneled authentication

Re: security paper on tunneled authentication

Re: security paper on tunneled authentication

Re: security paper on tunneled authentication

Re: security paper on tunneled authentication

How does cryptographic binding work

Re: How does cryptographic binding work

Re: How does cryptographic binding work

Re: How does cryptographic binding work