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

From: [email-masked] ([email-masked])
Date: Tue, 24 Sep 2002 14:51:09 +0300

Max,

Thanks again for your comments in the revised EAP SIM
doc. Please find some detailed responses below.

On client platform security, how about having the following text in the
security considerations. I want the text to be meaningful for
various platform security implementations.

"Because the network selects the RAND challenges and hereby the triplets, 
an attacker that knows two or three GSM triplets for the subscriber is able 
to impersonate a valid network to the client. Given physical access to 
the SIM card, it is easy to obtain any number of GSM triplets. Another way 
to obtain a RAND challenge and the corresponding SRES response of 
a GSM triplet is to eavesdrop on the GSM network. (To obtain the Kc key from 
the GSM network, the attacker needs to mount a brute force attach on encrypted 
data to find the Kc key by exhaustive search.) Yet another way to obtain triplets is 
to mount an attack on the client platform via a virus or other malicious piece of 
software. For these reasons, network authentication of EAP/SIM SHOULD NOT 
be used exclusively if strong network authentication is a concern. The client 
SHOULD be protected against triplet querying attacks by malicious software."

I think that RADIUS or GSM network security are not in the scope 
of this draft. I don't want to assume too big a role for this 
specification! If you want to have them discussed
somewhere, then maybe you should propose new text to
3GPP WLAN interworking specifications?

Having a table of versions is a good idea. I'll include one as soon as there 
are more than one version. I really don't think we should allocate any EAP SIM
version numbers for "vendor-specific" interpretations of the protocol. That would not 
be EAP SIM but something else. If someone needs such a thing, then she or he 
needs to get a new EAP type number or use the vendor-specific EAP type,
please see RFC2284bis (draft-ietf-pppext-rfc2284bis-06.txt).

I also think we need to improve the text on IMSI privacy. But I don't agree that
the client MUST send the IMSI whenever the network requests it. 
I believe that the client SHOULD NOT send the IMSI if it can reasonably believe
that the network should recognize the pseudonym. When to believe
such a thing is the issue that needs to be clarified. I'm not sure how
much we can say about this... This is perhaps something that needs to be 
discussed in 3GPP, because the network end implementation effects
this a lot.

About unsuccessful cases and EAP-Response/Nak: Nak is an EAP-level
thing, not an EAP-SIM concept. The RFC2284bis draft says that
NAK MUST NOT be used as a general purpose error indication.

Comment #5: Please note that K_int, K_encr etc. MUST NOT be used 
in 802.11 packet security but they are internal to EAP SIM.

I think it is good to quote the FIPS 186 PRNG, mainly because 
the FIPS doc is a bit misleading - it refers to wrong step numbers 
when it discusses how a general-purpose PRNG is "derived" from
the DSS PRGN algorithm. It is not totally obvious how to 
derive the correct PRNG.

I'll get back on the key derivation and MAC_RAND issues later.

Best regards,
Henry