RE: EAP-SIM -- Protected Start/Notifybefore fast-ReAuth
From: henry.haverinen (henry.haverinennokia.com)
Date: Wed, 25 Aug 2004 01:34:51 -0400 (EDT)
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
> 

Results generated by Tiger Technologies using MHonArc.