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

From: Uma Shankar Ch <[email-masked]>
Date: Wed, 25 Aug 2004 12:08:48 +0530

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 [email-masked] 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: [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
 > > >