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

From: [email-masked] (Max DE-GROOT)
Date: Tue, 17 Sep 2002 16:16:54 +0200

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"

---

From: [email-masked] (Joseph Salowey)
Date: Wed, 18 Sep 2002 04:42:50 -0700

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