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

[Bernard Aboba (aboba]

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

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

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

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

Yes.

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

That would be good.

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

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

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

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