eap Mailing List: RE: RFC 3748 Review of EAP SIM

[henry.haverinen (henry.haverinen]

Bernard,

Many thanks for your review. Please see below.

> 1. Does the method document its security properties
> in sufficient manner, as required by Section 7.2
> of RFC 3748?
> 
> Yes.  Documentation is provided.
> 
> However, there are some cases where clarity could be improved:
> 
> Section 1
> 
>    In any case,
>    if the GSM authentication mechanisms are considered to be 
> sufficient
>    for use on the cellular networks, then EAP-SIM is expected to be
>    sufficiently secure for other networks.
> 
> [BA] What other networks are being referred to?  If the claim is that
> EAP SIM is sufficiently secure for use on WLAN, then you need to
> reference draft-walker-ieee802-req-04.txt and include the additional
> claims defined in that draft within the security claims section.

For simplicity, I think we can delete this sentence from the introduction.

> Section 3
> 
>    Triplets may be stored in the EAP server for use at a later
>    time, but triplets may not be reused, except in some error 
> cases that
>    are specified in Section 9.9
> 
> [BA] Don't you  mean MUST NOT be reused?


Yes, we'll change this to "...triplets MUST NOT be reused, except..."

> 
> Section 11.7
> 
>    Because EAP-SIM is not a password protocol, it is not vulnerable to
>    dictionary attacks.  (The pre-shared symmetric secret stored on the
>    SIM card shall not be a weak password.)
> 
> [BA] perhaps better to say "is not a passphrase, or derived from a
> passphrase."
> 

OK. The new text would be "The pre-shared symmetric secret stored on
the SIM card is not a passphrase, or derived from a passphrase."

>    Because this attack requires the attacker to build a rogue GSM base
>    station (or at least eavesdrop the GSM traffic), the cost of the
>    attack is not negligible; it is the same cost as usually in GSM.
> 
> [BA] Building a rogue GSM basestation and eavesdropping on GSM traffic
> will have different costs.  So "same cost as usually in GSM"
> is not specific.  I'd delete this phrase.
> 

OK.

>    However, due to several weaknesses in the GSM encryption 
> algorithms,
>    the effective key strength of the Kc keys is much less than the
>    expected 64 bits (no more than 40 bits if the A5/1 GSM encryption
>    algorithm is used; as documented in [Barkan et al.  2003], 
> an active
>    attacker can force the peer to use the weaker A5/2 
> algorithm that can
>    be broken in less than a second).
> 
>    Because the A5 encryption algorithm is not used in EAP-SIM, and
>    because EAP-SIM does not expose any values calculated from 
> individual
>    Kc keys, it should be noted that these attacks are not possible if
>    the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.
> 
> [BA] My understanding is that sharing of a SIM between GSM/GPRS and
> WLAN is likely to be quite popular due to the convenience factor.
> Given the security implications, do the authors wish to make a
> recommendation relating to this scenario (e.g. sharing is NOT
> RECOMMENDED).

The draft spells out the consequences of sharing, as they are at the time
of writing. As Jari already commented, new improvements are being speficied 
at 3GPP.

This is merely an EAP method protocol specification, not a system specification
for the whole operator system. So I don't believe this document should make 
recommendations about the SIM credentials reuse. Ultimately, this decisions 
belongs 
to the operator's security responsibles, who can properly measure the 
"convenience" 
or cost versus the consequences of sharing, especially since 
the scenario may depend on the operator's GSM/GPRS implementation.

> [Optional, at least for now: does it conform to EAP
> keying framework?]
> 
> I believe that it does.  One issue that may arise is the lack 
> of an EAP
> Server identity.  This could have implications for handoff 
> mechanisms that
> require a NAS to fetch a key from the server, since the 
> server identity is
> not authenticated.

OK -- I believe we cannot do anything about this right now, especially
as the keying issues are work in progress, but we may need to reconsider 
this later.

> 3b. Does the method comply with sequence usage as defined
> in Section 2.1 of RFC 3748?
> 
> There is an odd statement in Section 11.12:
> 
>    There are man-in-the-middle attacks associated with the use of any
>    EAP method within a tunneled protocol such as PEAP, or within a
>    sequence of EAP methods followed by each other.
> 
> [BA] Since sequences are prohibited in [RFC3748], some mention of that
> prohibition is probably appropriate.  Otherwise one might read the
> paragraph as implying that EAP SIM could be used as part of a 
> sequence.

Thanks for spotting this. The text is quite old, written before the sequence 
and tunneling issues were fully resolved in RFC 3748. I think we should remove 
the remark about sequences, but keep this paragraph for the tunneling.
How about this revised text:

   There are man-in-the-middle attacks associated with the use of any 
   EAP method within a tunneled protocol such as PEAP. This specification 
   does not address these attacks. If EAP-SIM is used with a tunneling 
   protocol, there should be cryptographic binding provided between the 
protocol 
   and EAP-SIM to prevent man-in-the-middle attacks through rogue 
   authenticators being able to setup one-way authenticated tunnels. The 
   EAP-SIM Master Session Key MAY be used to provide the cryptographic binding. 
   However the mechanism how the binding is provided depends on the 
   tunneling protocol and is beyond the scope of this 
   document.

> I think there is an issue with the IANA considerations
> section.
> 
> An IANA registry is requested for the Subtype and Attribute
> Type number, allocated using "specification required".  No
> review mechanism is specified, yet it is indicated that the
> same protocol numbers should be assigned to EAP AKA and EAP
> SIM.  It is not clear how this requirement is to be enforced,
> given the allocation policy.  The authors may wish to rethink this.

Maybe we should request a common register for EAP-SIM and EAP-AKA
protocol values. That would ensure that numbers are non-overlapping.

Best regards,
Henry