eap Mailing List: RE: EAP-SIM -- Protected Start/Notifybefore fast-ReAuth

[henry.haverinen (henry.haverinen]

Uma,

If EAP-SIM and a protected lower layer such as IKEv2 or PEAP are used together, 
then 
it might not be necessary to use EAP-SIM fast re-authentication. 
PEAP supports session resumption, which can be used instead of running the 
full exchange. I guess EAP-SIM fast re-authentication would not
be necessary with IKEv2 either, unless for example the environment in
question requires frequent IKEv2 re-establishment from scratch. The EAP-SIM 
fast 
re-auth procedure could be used even as the first EAP exchange 
with a new IKEv2 gateway, for example.

About avoiding some attacks by applying K_aut in fast re-authentication,
I fully agree there would be protocol exchanges where K_aut could be
used. But both the server and the client would still have the possibility
to fall back to full authentication without ever proving knowledge of the
old K_aut. So if I was an attacker, I would not try to attack on the
sequence that uses K_aut upon the first messages, but instead I'd apply the 
fall back procedure, hence not needing the old K_aut at all. So in practice 
the level of security might not improve after all. 
As Joe already wrote, using K_aut in the first messages is not possible in the
current version of the protocol. 

Best regards,
Henry

> -----Original Message-----
> From: ext Uma Shankar K Ch [mailto:umas [at] intoto.com]
> Sent: 24 August, 2004 23:15
> To: Haverinen Henry (Nokia-ES/Jyvaskyla)
> Cc: jsalowey [at] cisco.com; umas [at] intotoinc.com; eap [at] frascone.com
> Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth
> 
> 
> 
> Hi Henry,
> 
> I understand the point made by you. As you said because of state 
> expiry or reboot, client may not maintain the K_aut key and with this 
> start request and it eventually fall back to full 
> authentication. But, the 
> only point we thought is, any way fast re-authentication 
> request would be 
> protected by K_aut key, just after getting the Fast-Re 
> authentication ID 
> in SIM Start Response, we had put a thought how it would be, 
> to protect 
> even EAPRequest/SIM/Start/AT_ANY_ID message and the corresponding 
> response so that some more attacks can be reduced.
> 
> As said by Joe, it is mentioned couple of times in the draft 
> regarding the 
> Identity protection offered by SIM Draft, which is much better in 
> comparision with GSM TMSI. And in Section 9.1 illustrated the 
> use of PEAP 
> for better security and better Identity Privacy.
> 
> 
> Ofcourse, this is an another issue:
> Even if IKEv2 is used as lowe layer, at the time of 
> EAP authentication server wouldn't authenticate client, (of course it 
> would be encrypted with the session keys genrated in IKE Init 
> exchange) 
> ie., final auth payload MUST be encrypted with  the MSK 
> generated by the EAP mutual 
> authentication method. 
> 
> When IKEv2 and EAP-SIM are used, I am not able to visualize 
> when Fast-Re 
> authentication feature would be used by IKE Responder.
> 
> Thanks for the response,
> Uma
> 
> 
> 
> 
> On Wed, 25 Aug 2004 henry.haverinen [at] nokia.com wrote:
> 
> > 
> > Joe, Uma,
> > 
> > Just to add some rationale for the chosen behaviour with regard 
> > to not using the K_aut to protect the first messages of the
> > re-authentication procedure. If we used K_aut, then we would
> > have to specify the corner cases when either the server or the
> > client does not have the K_aut key anymore, for example due
> > to reboot or state expiry. We cannot assume the server or the
> > client to always maintain this information reliably.
> > 
> > We concluded that in order to avoid deadlocks, there would 
> have to be 
> > a way to start full authentication from scratch, without 
> using the old K_aut;
> > hence the possibility of a DoS attack or an active identity 
> privacy attack
> > could not be avoided even if K_aut could be used when 
> everything goes fine. 
> > So the extra complexity of using K_aut didn't seem justified.
> > 
> > Best regards,
> > Henry
> > 
> > > -----Original Message-----
> > > From: eap-admin [at] frascone.com 
> > > [mailto:eap-admin [at] frascone.com]On Behalf Of
> > > ext Joseph Salowey
> > > Sent: 23 August, 2004 08:49
> > > To: 'Uma Shankar Ch'; eap [at] frascone.com
> > > Subject: RE: [eap] EAP-SIM -- Protected 
> Start/Notifybefore fast-ReAuth
> > > 
> > > 
> > > Hi Uma,
> > > 
> > > Thanks for a detailed review of the document.  Comments 
> inline below. 
> > > 
> > > Joe
> > > 
> > > Uma Shankar Ch wrote:
> > > > Can any body answer this query -- from
> > > > "draft-haverinen-pppext-eap-sim-13.txt" 
> > > > 
> > > > 
> > > > As of now,the protected  Notification are valid only after 
> > > successful
> > > > EAP-Request/SIM/Challenge round trip in full authentication or
> > > > successful  EAP-Request/SIM/Re-authentication round trip in fast
> > > > re-authentication. IF the draft won't mandate protected 
> > > notifications
> > > > after successful authentication there is a possibility 
> for session
> > > > closure by the peer because of an attacker as mentioned 
> below.     
> > > > 
> > > > Consider the case, when server is going for fast 
> re-authentication
> > > > and for the same it has started with 
> EAP-Request/SIM/Start and at
> > > > that point of time even if, EAP server wants to send a 
> Notification
> > > > it MUST send a protected notify, otherwise an attacker 
> can always
> > > > force the peer to close the connection just by sending 
> a unprotected
> > > > Notification Failure followed by Failure.     
> > > >
> > > 
> > > [Joe] This is true, any notification sent in the clear will 
> > > result in a
> > > failure.  We chose not to attempt to protect from many 
> DOS attacks on
> > > EAP-SIM as there are many in the system that we can do 
> nothing about.
> > > Perhaps in the future a subsequent version of EAP-SIM will be 
> > > able to do
> > > better.  
> > >  
> > > > In the similar lines, before the fast re-authentication, the
> > > > EAP-Request/SIM/Start MUST be protected, if not a man 
> in the middle
> > > > attacker  can always force the peer to reveal the 
> permanent Identity
> > > > by changing the actual the EAP-Request/SIM/Start from 
> AT_ANY_ID to
> > > > AT_PERMENANT_ID_REQ. Where server is expecting a valid fast-re
> > > > authentication ID and for that peer would be responding with
> > > > Permanent Identity because of the Man-In-Middle attacker.      
> > > > 
> > > 
> > > [Joe] It is not possible to avoid this problem with EAP-SIM 
> > > alone.  The
> > > identity privacy offered by EAP-SIM is only slightly better 
> > > than what is
> > > provided by GSM TMSI.  Considerations for implementing 
> > > identity privacy are
> > > discussed in several places throughout the document including 
> > > section 9.1
> > > and section 4.2.2.5.  
> > > 
> > > > So, is it not advisable to send EAP-Request/SIM/Start or
> > > > EAP-Request/Identity under the protection of the K_auth 
> key derived
> > > > in full-authentication, before going for fast 
> re-authentication.  
> > > > 
> > > 
> > > [Joe] You are correct that the protection of these messages 
> > > can help reduce
> > > the problems you described above.  Unfortunately it is 
> not possible to
> > > protect these using EAP-SIM.  If this level of protection is 
> > > desired then a
> > > tunneling method such as PEAP,TTLS,EAP-FAST, or IKEv2 should 
> > > be used with
> > > EAP-SIM as an inner method.  
> > > 
> > >   
> > > 
> > > > Thanks in advance.
> > > > Uma S
> > > > 
> > > > www.intoto.com
> > > 
> > > _______________________________________________
> > > eap mailing list
> > > eap [at] frascone.com
> > > http://mail.frascone.com/mailman/listinfo/eap
> > > 
> > 
> 
>