Hi Henry,
I understand that most of EAP methods are
designed for both 2- and 3 party models. However, I do think the EAP master key
from EAP authentication only resides at the peer and the EAP server and so far
we are ok for both 2 and 3 party models. Now if you choose to implement a key
distribution based on the initial EAP authentication, you can choose to send
your master key to the NAS. I am ok with that too, as long as you are not doing
handovers. If you ARE doing handovers, then the master key should not be sent
to the NAS, because then after the handover both NAS will come to share the
same master key and if the idea is to use the master key to run a security
association protocol (such as a 4-way handshake) to arrive at peer-NAS temp
keys, then you will have a serious threat problem.
The fast re-authentication in this draft
seems to use the initial master key to derive temp session keys (section 5.1). So
based on what I said above, I am assuming it is the EAP server is the one who
keeps the master key (EAP server or NAS) and derives the temp keys would be
important in case fast re-authentication is used for handovers. So fast
re-authentication still needs to happen based on interaction with the EAP
server, even though you don't run all the initial EAP exchanges, correct?
Regards,
Madjid
-----Original Message-----
From: henry.haverinen [at] nokia.com
[mailto:henry.haverinen [at] nokia.com]
Sent: Monday, April 11, 2005 3:45
AM
To: Nakhjiri Madjid-MNAKHJI1; twieland [at] cisco.com
Cc: eap [at] frascone.com
Subject: RE: [eap] EAP-SIM fast
re-auth identity
The term "EAP server" simply
refers to the entity that implemens
the EAP-SIM server part. Usually this is
implemented in a AAA server.
The "authenticator" is a term
that EAP documents use for the first-hop entity
(NAS or 802.11 access point). In
principle, the EAP server could be
co-located in the NAS, but I don't think
this is likely in the case of EAP-SIM.
If the access technology requires an EAP
exhange upon a handover,
then you can run either mode of
EAP-SIM there (full or fast re-auth).
Unless pre-authentication is used, this
kind of handover is not likely to be
very smooth. If there is a need to
run an EAP exchange even through
you haven't moved to a new AP, you can
also run either mode.
EAP-SIM does not define when to use the
fast re-auth mode.
-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1
[mailto:Madjid.Nakhjiri [at] motorola.com]
Sent: 06 April, 2005 22:19
To: 'Thomas Wieland'
Cc: eap [at] frascone.com; Haverinen
Henry (Nokia-ES/Jyvaskyla); Nakhjiri Madjid-MNAKHJI1
Subject: RE: [eap] EAP-SIM fast
re-auth identity
Hi Thomas,
Thanks for being among helpful "other
people" J
Ok, I am not sure how fast
re-authentication protects the use identity, so I can understand if no
protection is provided, that would be one way to protect the permanent
identities such as IMSI.
But what I don't understand is how every
use of IMSI means use of new triplets?
Sure EAP-SIM draft says that it does not
allow re-use of triplets (I guess for full authentication), but from what I
understand the fast re-authentication does not use any triplets, so the
question of "re-use versus using fresh" should be moot.
I do have another issue with the fast
re-auth. Most of the sequence charts only show a peer and an authenticator.
Does this mean the authenticator is the NAS or that it is the EAP server? I am
trying to understand how this fits into a 3 party EAP authentication model and
whether the fast re-authentication can apply to handovers or it is just
re-authentication to the same authenticator?
Regards,
Madjid
-----Original Message-----
From: Thomas Wieland
[mailto:twieland [at] cisco.com]
Sent: Wednesday, April 06, 2005
2:41 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: eap [at] frascone.com;
henry.haverinen [at] nokia.com
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
motorola.com)