Subject: [eap] draft-haverinen-pppext-eap-sim-05

From: [email-masked] (Max DE-GROOT)
Date: Thu, 19 Sep 2002 18:19:09 +0200

Joe,

The authentication should be based on a nonce from the client (from the SIM), integrity not necessarily. Therfore there is a difference. 
Then if we compare from a high level EAP/AKA and EAP/SIM we see some analogy if we use MAC-RAND:
 
 			EAP/SIM				EAP/USIM
 challenge		AT_RAND				AT_RAND
 network auth.	AT_MAC_RAND				AT_AUTN
 user auth.		AT_MAC_SRES				AT_RES
 integrity		AT_MAC				AT_MAC
 IV			AT_IV					AT_IV
 encryption		AT_ENCR				AT_ENCR

Ragrds

Max

-----Original Message-----
From: Joseph Salowey [mailto:[email-masked]]
Sent: mercredi 18 septembre 2002 13:43
To: Max DE-GROOT
Cc: [email-masked]; [email-masked]
Subject: RE: [eap] draft-haverinen-pppext-eap-sim-05

Thanks Max,

In this case I don't see a big difference between a key used for integrity 
and authentication, they are both used to authenticate the source of a 
particular set of data.   I suppose we could require the use of both 
AT_MAC_RAND and AT_MAC.  Currently this seems redundant, but I need to look 
deeper into the approach taken with AKA and see how similar it is to the 
use of MAC_RAND.

Regards,

Joe

At 04:16 PM 9/17/2002 +0200, Max DE-GROOT wrote:
>Hi Joseph,
>
>in fact, there are several reasons:
>Firstly, in general, good cryptographic behaviour is to use a key and an 
>function only for one purpose, so integrity of data transmmitted should be 
>provided using integrity functions and integrity keys, authentication 
>through authentication functions and authentication keys.
>Authentication of end users is provided using challenge response schemes 
>or digital signatures. In both cases the response (or signature) computed 
>by the prover should be based on data transmitted by the verifier.
>If the same funtions and the same keys are used to provide integrity and 
>authentication services, and either services is attacked, the other is 
>exposed as well and vice versa.
>
>Secondly, it is wiser to base the authentication on a known scheme, in 
>order to limit the risks. Known schemes have been tested and scrutinized 
>for a long time, so their security risks are known. A new scheme is open 
>to all kind of attacks and the risks are not known yet.
>The use of MAC_RAND and MAC-SRES is similar to the use of existing schemes 
>as AKA, while the use of AT_MAC is completely new.
>One remark though, normally, the verifier sends a challenge to the prover 
>so MAC-RAND should be based on NONCE-MT as it was in one of the first 
>draft documents, a thing I overlooked in my corrected version. So I suggest
>MAC-RAND= HMAC-SHA1-128 (K_rand, n*RAND | NONCE-MT | Message Subtype)
>
>Ragards
>
>Max de Groot
>
>
>-----Original Message-----
>From: Joseph Salowey [mailto:[email-masked]]
>Sent: vendredi 13 septembre 2002 19:04
>To: Max DE-GROOT
>Cc: [email-masked]; [email-masked]
>Subject: Re: [eap] draft-haverinen-pppext-eap-sim-05
>
>
>Hi Max,
>
>I'm trying to understand why using AT-MAC to authenticate the RANDS and the
>rest of the EAP message is unacceptable from a security point-of-view.  Can
>you please elaborate on this?
>
>Thanks,
>
>Joe
>
>At 06:05 PM 9/13/2002 +0200, Max DE-GROOT wrote:
> >Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> >Content-Language: fr-FRA
> >
> >Dear Henry
> >
> >I have some remarks to draft 5 of EAP/SIM.
> >
> >The principle issues I have with the contents are:
> >
> >-The previous versions used MAC-RAND to authenticate the network, MAC was
> >used as an integrity check on the whole EAP packet. In this version (and I
> >believe from V4 on) MAC-RAND has been suppressed and now MAC is used to
> >authenticate the network and to verify integrity.
> >I can imagine that from a development point of view, things are made
> >easier like this, but from a security point of view, it cannot be accepted.
> >Furthermore, the calculation of MAC-RAND was quit similar to MAC-SRES,
> >which allowed for a balanced mutual authentication, which is not the case
> >when MAC is used.
> >
> >-There is a risk that an attacker spoofs a network if he can obtain valid
> >triplets. This is possible when an attacker has physical access to a SIM,
> >like stated in the document, but also when an attacker has logical access
> >to a SIM through an unprotected client (windows based PC connected to the
> >internet for example). Therefore, access to GSM functions like RUN GSM
> >ALGORITHM (returning the triplets) should be avoided when a SIM is
> >inserted in a client. This can be made possible if new specific EAP
> >commands are developed, allowing authentication with an HLR/AUC based on
> >the existing Ki and IMSI, but protecting the sensible triplets by
> >executing most of the authentication calculations internally.
> >
> >I reflected these major and some other corrections and comments in the
> >attached document.
> >
> >Best Regards
> >
> >
> >Max de Groot
> >Technical Marketing
> >GEMPLUS Card International
> >Tel: +33442365036 GSM: +33607479373 Fax: +33442364100
> >Content-Type: APPLICATION/msword
> >Content-Description: draft-haverinen-pppext-eap-gsmsim-06 gemplus
> >revisions.doc
> >Content-Language: fr-FRA
> >Content-Disposition: attachment;
> >filename="draft-haverinen-pppext-eap-gsmsim-06 gemplus revisions.doc"