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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Henry,

 

Thank you for sending a quick response. I don't have an issue with having a fast re-authentication method that is more lightweight than the full authentication as long as the security is not compromised. One thing I am not clear about is whether the procedure is intended for handovers or not. But that is a different issue. The point I was trying to understand is not why fast re-authentication is needed, it is why a different identity is being used. Please see inline.

 

Regards,

 

Madjid

 

-----Original Message-----
From: henry.haverinen [at] nokia.com [mailto:henry.haverinen [at] nokia.com]
Sent: Wednesday, April 06, 2005 3:34 AM
To: twieland [at] cisco.com; Nakhjiri Madjid-MNAKHJI1
Cc: eap [at] frascone.com
Subject: RE: [eap] EAP-SIM fast re-auth identity

 

Hi Madjid, Thomas,

 

Thomas already justified very well why there is a separate fast re-authentication procedure.

 

The use of separate identities on fast re-authentication is just one way to design the re-authentication

procedure. Alternatively, we could have used the same pseudonyms during fast re-authentication.

There are some benefits in using separate identities.

 

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?

 

 

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?

 

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?

 

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?

 

For example, some EAP-SIM server implementations use cryptographically generated

pseudonyms that contain the IMSI, but use short number IDs as re-authentication identities.

(However, 3GPP decided to use the same format for both types of identities in release 6 specifications.)

 

Regards,

Henry 

 

 

-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com]On Behalf Of ext Thomas Wieland
Sent: 06 April, 2005 10:41
To: Nakhjiri Madjid-MNAKHJI1
Cc: eap [at] frascone.com; Haverinen Henry (Nokia-ES/Jyvaskyla)
Subject: Re: [eap] EAP-SIM fast re-auth identity

Hi Madjid,

  I'm not an author but "other people", but maybe I can shed
some light on this.  Henry can always correct and expand.

There is nothing "wrong" with the identities used during full
authentication (i.e. either permanent identity, e.g. 1IMSI @realm,
or pseudonym identity).  The "problem", if you will, is that by
definition of a full authentication, these identities require the
use of 2 or 3 GSM triplets to authenticate. 

For one, this implies at least one round trip to a remote server,
i.e. the HLR/AuC where the triplets are generated.  This is
usually much slower than going through the calculations
necessary to iterate the keying material locally at the AAA
server.  It also means additional load on the HLR/AuC.

The second "bad" aspect is that each full EAP-SIM authentication uses
up 2 or 3 triplets.  The number of triplets that can be generated by each
SIM is usually limited (e.g. to 50,000) due to security concerns.  This
doesn't matter too much in a GSM mobile network as authentications
only use only one triplet and occur relatively infrequently compared to,
for example, public WLAN.  For EAP-SIM used in a PWLAN scenario,
not only do you use up 2 or 3 triplets per authentication, the authentications
also happen much more frequently.  For example every time every time
a PC gets turned on (or woken up), when a user roams between access
points etc.  You can see how you could be chewing through the available
triplets pretty fast and once you've reached the limit hard-wired into the
SIM, your SIM is dead and needs to be replaced. 

By using the fast re-auth mechanism, not only do you speed up
EAP-SIM authentications (hence "fast" :-), you also reduce the
load on the back-end server (AuC) and extend the life of your SIM.
In other words, "it's a good thing".

Regards,

  Thomas



At 10:05 05-04-05 -0500, Nakhjiri Madjid-MNAKHJI1 wrote:

Hi,

 

I have a question regarding the EAP-SIM method for fast re-authentication and would appreciate it if the authors and other people respond. Why is a specific identity used for fast re-authentication? What is the problem with using the identities that were used during the full authentication? The initial identity that is sent in EAP-Response/ Identity should not have a problem, right?

 

Thanks in advance,

 

Madjid Nakhjiri

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