Subject: RE: [eap] EAP-SIM -- Protected Start/Notifybefore fast-ReAuth

From: <[email-masked]>
Date: Wed, 25 Aug 2004 08:48:46 +0300

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: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Joseph Salowey
> Sent: 23 August, 2004 08:49
> To: 'Uma Shankar Ch'; [email-masked]
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Mon, 30 Aug 2004 15:19:33 +0300

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

> From: ext Uma Shankar K Ch [mailto:[email-masked]]
> Sent: 24 August, 2004 23:15
> To: Haverinen Henry (Nokia-ES/Jyvaskyla)
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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 [email-masked] wrote:
> 
> > 
> > Joe, Uma,
> >