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
nokia.com)