eap Mailing List: RE: EAP-SIM fast re-auth identity

[henry.haverinen (henry.haverinen]

Hi Madjid,

 

Please see in line.

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com]
 

 

-----Original Message-----
From: henry.haverinen [at] nokia.com [mailto:henry.haverinen [at] nokia.com] 
 

Thanks to the separate identities, fast re-authentication and full authentication can be implemented

separately, more modularly, at the server.

 

Madjid>>Can't both modules use the same identity for the peer? I am guessing for fast re-auth you need to locate the MK, can't you do it with the same identity as the one you used for full authentication?

 

Yes, if we had designed the protocol differently :-)

 

This all relates to the management of temporary identities. If you want to use

a separate identity upon each EAP exchange, and if you perform a full authentication

after a fast re-authentication, then the last temporary identity that you distributed

during fast re-authentication would have to be available to the module that

performs full authentication.

 

When the server runs fast re-authentication, it does not have

to update the information about the full authentication pseudonym. Fast re-authentication

could even be distributed to a separate entity, a separate subsystem of the EAP server that

does not need to have any access to the triplets or to other "long-term" state of the subscriber.

 

Madjid>> why do you need the triplets for fast re-authentication. Isn't the user id and MK enough?

 

You don't need triplets for fast re-authentication. The fast-reauthentication id, the

counter, and the MK are enough.

 

A separate fast-reauthentication identity also indicates to the server that the client wants to use

fast re-authentication. Hence it is possible to "overload" the identity with this indication and

save a roundtrip in some cases.

 

Madjid>>Couldn't this be done with the same identity by some sort of flag or subtype?

 

Yes. In this procol, we did it with a separate identity.

 

When there are several AAA servers, pseudonyms should be decodable by all the servers

at the home network. They should also be decodable a long time after they were delivered.

Hence, the storing mechanism for pseudonyms is likely to be "expensive". Fast re-authentication

identities can be locally administered by a single server, and it does not matter if they are

not stored so "reliably".

 

Madjid>> I guess it depends on how fast re-auth ID is created/ communicated to the local server.

I am guessing fast re-auth ID is generated after a full authentication with a perm. ID is performed and the master key is sent from the central server to the local server. If the MK is sent to the local server processing the fast re-auth, why not send the perm. ID with it? Unless you want to protect the perm. ID from the local server?

 

As said, this relates to the use of temporary identities, which are used instead of the permanent identity

for privacy reasons.  If there were scenarios where fast re-authentication would be distributed closer to

the access network (which I am not aware of, BTW ), and if you want to use temporary identities, then

it is better to have a separate identity "space" for the local server to administer -- just as we

have currently in EAP-SIM.

 

EAP-SIM does not allow the use of the permanent identity upon fast re-authentication. This

is not a problem, since the server needs to keep state anyway, so the identity can

be managed as part of the other state.

 

Regards,

Henry