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

[Joseph Salowey (jsalowey]

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

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

> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap