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

From: [email-masked] (Max DE-GROOT)
Date: Mon, 23 Sep 2002 10:54:37 +0200

Hello Henry.

Some remarks as I do not agree with your point of view.

AT-MAC-RAND is not redundant with AT-MAC. In fact the former is based on a challenge from the card, the latter is not. I recognize that the K-int is derived in some sort form the NONCE-MT, but that is not the point. The verifier shall send a challenge to the prover, the prover uses this challenge and a secret key to calculate a cryptographic result that wil be verified by the verifier. The card in our case. 
The same happens with the RAND sent by the network and the SRES calculated by the card. That is a real challenge response mechanisme. We shall introduce that to EAP/SIM (an in fact, to EAP/AKA as well, but we will get to that some other time ;))
AT-MAC is not based on a challenge from the card, and can therefore not be considered as an authentication.

Then about the use of the same key for different purposes, I am in good company of Bruce Schneier who writes in his 'Applied Cryptography, 2nd edition, sect. 8.9:
"This is a serious problem and brings to light the dangers of Alice tying all of her identities to a single key. It would be better for Alice to have different keys for different applications.....".

Therefore AT-MAC-RAND shall be used for network authentication and AT-MAC for Message integrity. (By the way, we should call it AT-MIC, Message Integrity Code.)

Finally, reacting on your last point: If EAP/SIM is implemented in a GSM phone and the SIM environment (algorithm, IMSI, ADN) is accessible from the outside world, the same protection should be used as we define for WLAN. 

Best regards

Max

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vendredi 20 septembre 2002 12:40
To: Max DE-GROOT [GEMPLUS]
Cc: [email-masked]
Subject: RE: draft-haverinen-pppext-eap-sim-05

Hi Max,

Thanks for your comments. Sorry for not replying
before, I just returned back to the office.

W.r.t. MAC_RAND versus AT_MAC, I'm inclined to
agree with Joe in that a separate MAC_RAND seems
redundant and unnecessary. I don't think that the
fact that MAC_RAND resembles some other protocol
(the UMTS AKA AUTN parameter) is a sufficient reason 
to justify it. 
The AT_MAC attribute does exactly the same thing as 
MAC_RAND used to, and I cannot see any real security
reasons why AT_MAC wouldn't work, or any implementation
reasons why it wouldn't work even on a special EAP smart 
card that you referred to.

K_int is not a multi-purpose key but rather it is only 
used for calculating HMAC-SHA1-128 values in EAP-SIM.
It is OK to use the same key for calculating several MAC
codes.

The draft is a protocol specification for an EAP method and 
it doesn't preclude or advocate any terminal implementation 
alternatives. The concern on retrieving triplets with the 
RUN GSM ALGORITHM function applies to all environments where
GSM SIMs are used, and this is already discussed in
the security considerations section. To me it doesn't make
sense to try to ban the use of this function in the EAP SIM
specification. What if EAP SIM is implemented on a GSM phone 
for PPP authentication? So I think that the current discussion
in security considerations is sufficient.
Although not precluded by the draft, I don't think that new 
EAP functions on smart cards are in the scope of the document
either.

Thanks for the editorial comments too. I agree that 
the discussion on IMSI privacy and the other points
you raised need to be clarified.

Best regards,
Henry

> -----Original Message-----
> From: ext Max DE-GROOT [mailto:[email-masked]]
> Sent: 13 September, 2002 19:05
> To: Haverinen Henry (NMP/Tampere)
> Cc: [email-masked]
> Subject: draft-haverinen-pppext-eap-sim-05
> 
> 
> 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
>