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

[Uma Shankar Ch (umas]

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
www.intoto.com




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 
> > >