Subject: [eap] RFC 3748 Review of EAP SIM

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Nov 2004 00:11:20 -0800 (PST)

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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Nov 2004 15:13:41 +0200

Thanks for the review, Bernard! Some further discussion

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

> [BA] Don't you  mean MUST NOT be reused?

I think so.

> [BA] perhaps better to say "is not a passphrase, or derived from a

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

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

> recommendation relating to this scenario (e.g. sharing is NOT

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.

> require a NAS to fetch a key from the server, since the server identity is

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?

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

> 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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Nov 2004 15:48:30 +0200

> given the allocation policy.  The authors may wish to rethink this.

Now I think I understand what your problem was. Would
it help if the document(s) stated that ONE registry of
parameters is established at IANA?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Nov 2004 07:01:57 -0800 (PST)

> document would benefit from listing those claims too.

I just was asking about whether a claim was being made.  If not, then that
sentence can be deleted.

> Do you mean in addition to not being a weak password, or as a

I meant as a replacement.  The term "weak password" is somewhat ill
defined -- but Ki is not a passphrase at all, so stating that might make
it clearer.

Yes.

> the impact of 3GPP developments into this problem, however.

That would be good.

> communicated to the (new) NAS?

I mention this because of the importance of authenticated peer and server
names in several of the 802.11r proposals.  The authenticated peer name is
utilized as the identity in some of the proposals, so that EAP methods
which don't include this might not function.  Luckily, I think most
methods have this (it's a SHOULD in RFC 3748).

What was somewhat surprising to me is that there was also talk about a
message sent from the peer to the new NAS, requesting that a key be
provisioned, by name.

The new NAS might have more than one RADIUS server, which might
include the RADIUS server used by the old NAS, on which key state (EMSK)
still resides.  But that might not be the primary RADIUS server.  So in
that message, the peer may need to include the server name, so that the
new NAS can fetch the key from it.

This would impact the performance of methods that do not include an
authenticated server name.  I believe quite a few methods do not do this,
including EAP SIM, AKA and possibly EAP-TLS PSK mode. For that reason, I'm
not sure this kind of "key fetching" is a good idea, and it's not
supported in Diameter EAP.

> note be specific to PEAPv1 which did have that problem?

The man-in-the-middle part is ok as is;  I was only referring to
sequences.  I think that part is probably historic.

> exhausting attribute space?

Yes, Expert Review would address this, since the expert presumably could
ensure that the allocation was consistent with EAP AKA.  However, it also
could be addressed by creating a single registry for both EAP AKA and SIM,
so that inconsistency would be impossible.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Nov 2004 07:03:24 -0800 (PST)

> parameters is established at IANA?

Yes.  Presumably that registry would only be established and initial
values listed in one of the drafts;  the other could state "no registries
or parameter allocation required".

You'd save some time in IANA review, too ;)
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Nov 2004 17:46:17 +0200

> message sent from the peer to the new NAS, requesting that a key be

Would this be a "key name" (as defined in eap-keying), the identity
of the AAA server in some AAA level representation (e.g.
Destination-Host AVP), or the identity that the peer saw for the
server when it initially authenticated with it? Note that all these
name spaces may be separate, and might not be possible for the
client to discover the Destination-Host AVP or for the NAS to
use either the key name or the method-internal server name for
any purpose.

> new NAS can fetch the key from it.

So the problem is about routing to the right AAA node? I don't think
the EAP server name guarantees that. What if the same cert and key
pair is shared between the primary and backup servers?
One working solution would be for the EAP server to pass its
"AAA address" via EAP to the client, but this feels like a hack
at least on initial look. Alternatively, the old NAS could
hand the AAA route or destination it used to the client, and
the client could hand it to the new NAS.

> For that reason, I'm

Agreed.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Nov 2004 08:22:49 -0800 (PST)

> use either the key name or the method-internal server name for

The Key-Name is needed so that the NAS knows what to ask for.  For this
purpose the EAP Session-Id should be sufficient.  The other info that is
required is which AAA server to send the request to.  I think this needs
to be an FQDN resolvable to an IP address, or an IP address.

As you note, even in protocols that provide an authenticated EAP server
name, this might not be fulfilled.  For example, multiple AAA servers can
use the same certificate ("aaa.example.com"), so that the altSubjectName in the
server certificate might not be specific enough.

> the EAP server name guarantees that.

Right.  I don't think it does.

> What if the same cert and key

That's a common practice, and I think it will break this scheme, even for
protocols that provide an authenticated EAP server name.

> > supported in Diameter EAP.

This is an example of something that needs to be discussed in the EAP
Keying document, to make sure people are aware of the "gotchas".
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 22 Nov 2004 08:36:16 -0800

>>> 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?
> 
> I mention this because of the importance of authenticated
> peer and server names in several of the 802.11r proposals.
> The authenticated peer name is utilized as the identity in
> some of the proposals, so that EAP methods which don't
> include this might not function.  Luckily, I think most
> What was somewhat surprising to me is that there was also
> talk about a message sent from the peer to the new NAS,
> requesting that a key be provisioned, by name.
> 
> The new NAS might have more than one RADIUS server, which
> might include the RADIUS server used by the old NAS, on which
> key state (EMSK) still resides.  But that might not be the
> primary RADIUS server.  So in that message, the peer may need
> to include the server name, so that the new NAS can fetch the
> key from it.
> 
> This would impact the performance of methods that do not
> include an authenticated server name.  I believe quite a few
> methods do not do this, including EAP SIM, AKA and possibly
> EAP-TLS PSK mode. For that reason, I'm not sure this kind of
> "key fetching" is a good idea, and it's not supported in Diameter EAP.
> 

[Joe] This sounds like a problem with an 802.11r
implementation/specification to me, the information on how to perform
roaming should be part of 802.11r, not EAP.  The AuC is authenticated.     

>>> [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. 
>> 
>> binding support exist, this is less of an issue. Or should the note
>> be specific to PEAPv1 which did have that problem?
> 
> The man-in-the-middle part is ok as is;  I was only referring
> to sequences.  I think that part is probably historic.
> 
[Joe] We can just remove the text referring to the sequence.

>>> 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?
> 
> Yes, Expert Review would address this, since the expert
> presumably could ensure that the allocation was consistent
> with EAP AKA.  However, it also could be addressed by
> creating a single registry for both EAP AKA and SIM, so that
> inconsistency would be impossible.

[Joe] I think that would be good.