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

[Jari Arkko (jari.arkko]

Thanks for the review, Bernard! Some further discussion
from my point of view:

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

Information on compliance to draft-walker might indeed be
useful. OTOH, we will probably never have methods document
their compliance to all possible usage scenarios. From the
looks of it, EAP SIM fulfills the draft-walker requirements,
but I wouldn't necessarily *require* the draft to be changed
unless the authors have some text ready for this. But the
document would benefit from listing those claims too.

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

I think so.

> 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."

Do you mean in addition to not being a weak password, or as a
replacement of the text?

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

Yes, or reformulate. I guess the point was that the cost of GSM
components may be a bit higher than some other similar technology
(e.g. WLAN AP). But you certainly don't need a full network. So
"same cost" is not very well defined.

>    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).

Perhaps the main thing is that the implications are spelled
out. Which is already done, I think.

Recommendation against sharing might be wise, but then again
it might not be. One specific issue is that 3GPP is addressing
the A5/2 problem as well as other things that caused the Barkan
et al problem, and when those techniques are in use (I believe
some early parts of those techniques are here soon) then sharing might
again be OK. So given the fluid situation I'd rather not recommend
anything. Perhaps the document should have some statement about
the impact of 3GPP developments into this problem, however.

> [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.

Hmm... we may not have explored the handoff design far enough to
say for sure, but its not immediately obvious to me that the
server identity helps here. There's certainly a key which is
shared between the server and the client. And key identifiers,
if the eap keying framework defines them. Plus even if the
server was identified, how would that identification be
communicated to the (new) NAS?

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

Is this text a part of some now historic note? I would assume that
since RFC 3748 prohibits sequences and tunneling protocols with
binding support exist, this is less of an issue. Or should the
note be specific to PEAPv1 which did have that problem?

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

I'm not quite sure what the specific problem is, but would
Expert Review address this, as well as remove concern for
exhausting attribute space?

--Jari