eap Mailing List: RFC 3748 Review of EAP SIM

[Bernard Aboba (aboba]

RFC 3748 Review of draft-haverinen-pppext-eap-sim-15r1

The following list of issues is provided as a guideline to potential
expert reviewers and method authors.

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.

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?

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

   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.

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

1a. Mechanism. Is the mechanism explained?

Yes. See Section 12.

1b. Security claims. Are the claimed and not claimed
properties listed?

Yes. See Section 12.

1c. Justifications for the claims? Is an explanation or
reference provided to each of the claims?

Explanations or references are provided in Sections 11 & 12.

1d. Key strength. Is the key strength documented?

Yes. Issues relating to key strength are documented in Section 11.5.

1e. Description of key hierarchy. Is the key hierarchy
documented?

Yes.

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

1f. Indication of vulnerabilities. Are the known vulnerabilities
documented?

Yes.  Reference is made to the Barkan and Patel papers.

[Note: it seems unreasonable to require the documentation
of unknown vulnerabilities :-) The "known" may of course be
"known to reviewer" or "known to author" or "known to the
community", but that appears to be best we can do.]

2. Compliance with EAP packet formats

2a. Does the method comply with the packet formats
defined in Section 4 of RFC 3748?

Yes.

3. Compliance with EAP behaviour

3a. Does the method comply with Success/Failure usage
as defined in Sections 2, 2.2, and 4.2?

Yes.  See Section 6.2 and 6.3.

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.

3c. Does the method comply with request/response processing
rules as defined in Section 4.1 of RFC 3748?

Yes.

3d. Does the method comply with retransmission rules
as defined in Section 4.3 of RFC 3748?

Yes.

3e. Does the method comply with the usage defined for
Identity, as defined in Section 5.1 of RFC 3748?

Yes.  See Section 4.2.

3f. Does the method comply with the usage defined for
Notification, as defined in Section 5.2 of RFC 3748?

Yes. See Section 6.1.

3g. Does the method comply with the usage defined for
Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?

Yes.

3h. Does the method comply with the MIC usage requirements
from Sections 3.1, 7.5, and 7.8 of RFC 3748?

Yes.

3i.  Does the method define a method-specific peer identity,
   rather than utilizing the EAP-Response/Identity?

Yes.

4. Compliance with IANA requirements

4a. Does the method comply with EAP-based IANA requirements
defined in Section 6 of RFC 3748? That is, if it requests
the allocation of new numbers in the EAP namespace [not
applicable if the numbers have already been allocated],
is the type of the document and process appropriate for the
desired action?

A Type code has already been allocated.

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.

4b. Does the method comply with other IANA requirements in
the IETF standards track RFCs? For instance, does the
method attempt to allocate TLS extensions (which would
only be possible for standards track RFCs)?

Yes.