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

From: [email-masked] ([email-masked])
Date: Fri, 20 Sep 2002 13:39:51 +0300

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=20
to justify it.=20
The AT_MAC attribute does exactly the same thing as=20
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=20
card that you referred to.

K_int is not a multi-purpose key but rather it is only=20
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=20
it doesn't preclude or advocate any terminal implementation=20
alternatives. The concern on retrieving triplets with the=20
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=20
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=20
EAP functions on smart cards are in the scope of the document
either.

Thanks for the editorial comments too. I agree that=20
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
>=20
>=20
> Dear Henry
>=20
> I have some remarks to draft 5 of EAP/SIM.
>=20
> The principle issues I have with the contents are:
>=20
> -The previous versions used MAC-RAND to authenticate the=20
> network, MAC was used as an integrity check on the whole EAP=20
> packet. In this version (and I believe from V4 on) MAC-RAND=20
> has been suppressed and now MAC is used to authenticate the=20
> network and to verify integrity.
> I can imagine that from a development point of view, things=20
> are made easier like this, but from a security point of view,=20
> it cannot be accepted.=20
> Furthermore, the calculation of MAC-RAND was quit similar to=20
> MAC-SRES, which allowed for a balanced mutual authentication,=20
> which is not the case when MAC is used.
>=20
> -There is a risk that an attacker spoofs a network if he can=20
> obtain valid triplets. This is possible when an attacker has=20
> physical access to a SIM, like stated in the document, but=20
> also when an attacker has logical access to a SIM through an=20
> unprotected client (windows based PC connected to the=20
> internet for example). Therefore, access to GSM functions=20
> like RUN GSM ALGORITHM (returning the triplets) should be=20
> avoided when a SIM is inserted in a client. This can be made=20
> possible if new specific EAP commands are developed, allowing=20
> authentication with an HLR/AUC based on the existing Ki and=20
> IMSI, but protecting the sensible triplets by executing most=20
> of the authentication calculations internally.=20
>=20
> I reflected these major and some other corrections and=20
> comments in the attached document.
>=20
> Best Regards
>=20
>=20
> Max de Groot
> Technical Marketing
> GEMPLUS Card International
> Tel: +33442365036 GSM: +33607479373 Fax: +33442364100
>=20