headers
Joseph Salowey (jsalowey | 2 Oct 2007 18:20
Picon
Favicon

RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls


> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba <at> hotmail.com] 
> Sent: Monday, September 17, 2007 10:20 AM
> To: Joseph Salowey (jsalowey); emu <at> ietf.org
> Cc: ecrit-chairs <at> tools.ietf.org; Bernard_Aboba <at> hotmail.com
> Subject: RE: Draft liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> It is not clear to me whether the requirements do in fact 
> prohibit server-side authentication.  As you note, without 
> server-side authentication man-in-the-middle attacks are 
> possible;  however, even with server-side authentication, 
> additional requirements may need to be imposed in order to 
> provide the desired level of security.
> 
> Requirement #1 is "No Pre-configured trust relationship".  
> This could refer to pre-configuration of the server with 
> respect to the expected client credential (PSK or 
> certificate), or it could refer to pre-configuration of the 
> client with respect to the server, (such trust anchors).  The 
> text seems focused on the former more than the latter.  
> Assuming that clients can be pre-configured with trust 
> anchors, then TLS-based EAP methods could meet the requirement.

[Joe] I agree, that if "No pre-configured trust relationship" refers to
configuration of client on the server then we are in a better position.
However it seems that in you discussion below that the peer does not
typically have enough information to validate the server. 
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joseph Salowey (jsalowey | 2 Oct 2007 18:54
Picon
Favicon

RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

Hi Hannes,

Comments inline below. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig <at> gmx.net] 
> Sent: Saturday, September 22, 2007 6:23 AM
> To: Bernard Aboba
> Cc: Joseph Salowey (jsalowey); emu <at> ietf.org; 
> ecrit-chairs <at> tools.ietf.org; ECRIT
> Subject: Re: Draft liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> Hi Bernard,
> 
> thanks for your input. Please find a few more thoughts below:
> 
> Bernard Aboba wrote:
> > It is not clear to me whether the requirements do in fact prohibit 
> > server-side authentication.  As you note, without server-side 
> > authentication man-in-the-middle attacks are possible;  
> however, even 
> > with server-side authentication, additional requirements 
> may need to 
> > be imposed in order to provide the desired level of security.
> >
> I also believe that the requirements does not rule out 
> server-side authentication.
> 
> > Requirement #1 is "No Pre-configured trust relationship".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 2 Oct 2007 22:03
Picon
Favicon

RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

>[Joe] I agree, that if "No pre-configured trust relationship" refers to
>configuration of client on the server then we are in a better position.
>However it seems that in you discussion below that the peer does not
>typically have enough information to validate the server.

I think we need to distinguish between "validating the server" and 
"validating the authenticator".  If the EAP peer has trust anchors, it can 
validate the server.  The question is whether that should be sufficient to 
allow the peer to connect to the authenticator or not.

It may matter whether the peer has a pre-existing profile.   For example, if 
there is a profile corresponding to the "EXAMPLE" network, and the peer 
successfully validates the "example.com" server, then the question is 
whether the peer should apply the "EXAMPLE" profile based on validation of 
the "example.com" server certificate.  If the "EXAMPLE" profile includes a 
requirement for validation of a certificate from "example.com", then that 
should be sufficient.

However, if there is no pre-existing profile then it is not clear to me what 
security services can be required.  Should the peer be satisfied if the 
server certificate chains to any trust anchor, regardless of the SSID?  If 
the SSID in question represents a pre-existing profile requiring chaining to 
a particular trust anchor, I'd say "no".  However, if the SSID is unknown 
and there is an unknown SSID that advertises emergency services, then it is 
probably better to try that (and maybe even go ahead if the server cert 
fails validation) than to fail -- leaving the user without the ability to 
make an emergency call in a life and death situation.

> >
> > Requirement #2 is "Small" number of messages.  While this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joseph Salowey (jsalowey | 3 Oct 2007 20:02
Picon
Favicon

Moving forward with the EMU password method

At the IETF in Chicago we had a hum as to the direction we should take
with the password based method.  I would like to clarify the choices and
determine working group consensus on the list.  The two directions are
given below please express you preference by 10/25.

Option 1 - Password based method - this option restricts the work item
to what is currently in the charter.  The resulting method would have a
new method ID and selecting this method would mean selecting a password
based exchange that meets the requirements we already set forth.  The
method may use an existing method as its base.  

Option 2 - Tunneling method - this option requires clarifying the
charter to work on a tunneling method which would then be used to meet
the password method requirements.  This would include making sure we
have a valid set of requirements to work with. The working group may
select an existing method as its base and have backwards compatibility
as a goal, however whether the method uses the same method ID and any
modifications to the method will be determined by working group and IETF
consensus.  

Thanks,

Joe
Permalink | Reply | 7 comments |
headers
Stephen Hanna | 3 Oct 2007 21:54
Favicon

RE: Moving forward with the EMU password method

I favor option 2.

There are tunneling EAP methods already in widespread use that can meet
the requirements with a few extensions (e.g. EAP-TTLSv0 with the
extensions
documented in draft-hanna-eap-ttls-agility-00.txt). Customers are
understandably
reluctant to deploy new EAP methods so it's much more likely that they
will
use the results of our work if we use an existing EAP method instead of
defining a new method.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:jsalowey <at> cisco.com] 
Sent: Wednesday, October 03, 2007 11:03 AM
To: emu <at> ietf.org
Subject: [Emu] Moving forward with the EMU password method

At the IETF in Chicago we had a hum as to the direction we should take
with the password based method.  I would like to clarify the choices and
determine working group consensus on the list.  The two directions are
given below please express you preference by 10/25.

Option 1 - Password based method - this option restricts the work item
to what is currently in the charter.  The resulting method would have a
new method ID and selecting this method would mean selecting a password
(Continue reading)

Permalink | Reply | 6 comments |
headers
Gene Chang (genchang | 3 Oct 2007 22:26
Picon
Favicon

RE: Moving forward with the EMU password method

I also favor option 2.
There are already several tunneling EAP methods in widespread use.
There is already concern that there are too many alternatives. We should
avoid introducing a new EAP method. It would be better to (a) use an
existing EAP method, (b) merge some of the existing methods, or (c) if
necessary, perfect an existing method to meet our needs.

Gene

------------------------------------------------------------------------
----
Eugene Chang (genchang)
Office:   603-559-2978
Mobile:  781-799-0233

 

> -----Original Message-----
> From: Stephen Hanna [mailto:shanna <at> juniper.net]
> Sent: Wednesday, October 03, 2007 3:55 PM
> To: Joseph Salowey (jsalowey); emu <at> ietf.org
> Subject: RE: [Emu] Moving forward with the EMU password method
> 
> I favor option 2.
> 
> There are tunneling EAP methods already in widespread use that can
meet
> the requirements with a few extensions (e.g. EAP-TTLSv0 with the
> extensions
> documented in draft-hanna-eap-ttls-agility-00.txt). Customers are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ray Bell | 4 Oct 2007 00:26

RE: Moving forward with the EMU password method

I favor option 2 as well

Ray

-----Original Message-----
From: Stephen Hanna [mailto:shanna <at> juniper.net] 
Sent: Wednesday, October 03, 2007 12:55 PM
To: Joseph Salowey (jsalowey); emu <at> ietf.org
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2.

There are tunneling EAP methods already in widespread use that can meet
the requirements with a few extensions (e.g. EAP-TTLSv0 with the
extensions
documented in draft-hanna-eap-ttls-agility-00.txt). Customers are
understandably
reluctant to deploy new EAP methods so it's much more likely that they
will
use the results of our work if we use an existing EAP method instead of
defining a new method.

Thanks,

Steve

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:jsalowey <at> cisco.com] 
Sent: Wednesday, October 03, 2007 11:03 AM
To: emu <at> ietf.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ryan Hurst | 4 Oct 2007 01:15
Picon
Favicon

RE: Moving forward with the EMU password method

I also favor #2, I like Steve have found customers reluctant to deploy
new methods if we can satisfy the goals with a method that's broadly
deployed (with some tweaks) I think we will have more success than if we
define a new one.

-----Original Message-----
From: Ray Bell [mailto:ray <at> grid-net.com] 
Sent: Wednesday, October 03, 2007 3:26 PM
To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu <at> ietf.org
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2 as well

Ray

-----Original Message-----
From: Stephen Hanna [mailto:shanna <at> juniper.net] 
Sent: Wednesday, October 03, 2007 12:55 PM
To: Joseph Salowey (jsalowey); emu <at> ietf.org
Subject: RE: [Emu] Moving forward with the EMU password method

I favor option 2.

There are tunneling EAP methods already in widespread use that can meet
the requirements with a few extensions (e.g. EAP-TTLSv0 with the
extensions
documented in draft-hanna-eap-ttls-agility-00.txt). Customers are
understandably
reluctant to deploy new EAP methods so it's much more likely that they
will
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hao Zhou (hzhou | 4 Oct 2007 04:56
Picon
Favicon

RE: Moving forward with the EMU password method

Me too. I like to see a standard based tunneling method, that supports
crypto-binding, crypto-agility, internationalization, as well as a
standard framework for extension within the tunnel. 

> -----Original Message-----
> From: Ryan Hurst [mailto:Ryan.Hurst <at> microsoft.com] 
> Sent: Wednesday, October 03, 2007 7:16 PM
> To: Ray Bell; Stephen Hanna; Joseph Salowey (jsalowey); emu <at> ietf.org
> Subject: RE: [Emu] Moving forward with the EMU password method
> 
> I also favor #2, I like Steve have found customers reluctant 
> to deploy new methods if we can satisfy the goals with a 
> method that's broadly deployed (with some tweaks) I think we 
> will have more success than if we define a new one.
> 
> -----Original Message-----
> From: Ray Bell [mailto:ray <at> grid-net.com]
> Sent: Wednesday, October 03, 2007 3:26 PM
> To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu <at> ietf.org
> Subject: RE: [Emu] Moving forward with the EMU password method
> 
> I favor option 2 as well
> 
> Ray
> 
> 
> -----Original Message-----
> From: Stephen Hanna [mailto:shanna <at> juniper.net]
> Sent: Wednesday, October 03, 2007 12:55 PM
> To: Joseph Salowey (jsalowey); emu <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Salowey (jsalowey | 4 Oct 2007 06:22
Picon
Favicon

RE: EAP-GPSK and Client-Side DoS Attacks

I think the problem is real, although not catastrophic.  I would prefer
not to remove the identity from the key derivation so either option 2 or
3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a
change to the existing draft.  Since we do not have many implementations
yet I would slightly favor 2.  

> -----Original Message-----
> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) 
> [mailto:hannes.tschofenig <at> nsn.com] 
> Sent: Thursday, September 20, 2007 1:51 AM
> To: emu <at> ietf.org
> Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks
> 
> Hi all, 
> 
> What is the issue? The first message from the server to the 
> peer is not authenticated. This may allow some kind of denial 
> of service attack against the peer. The peer should be ready 
> to accept new sessions from the same server, so the peer must 
> store one server nonce and one peer nonce for each message 1 
> it receives.  An attacker can then flood the network with 
> fake message 1s to overflow the peer's buffer.  This issue is 
> similar to an issue found in the 802.11i 4-way handshake.
> 
> When receiving message 1, the peer checks to see if it has 
> open conversations with the server listed in the message.  If 
> it does, then it will reuse the peer nonce it already sent.  
> In addition, it will not store the server nonce, since the 
> server nonce comes back in message 3.
> Message 3 then contains almost all the information necessary
(Continue reading)

Permalink | Reply | 0 comments |

Gmane