Subject: [eap] EAP pre-authentication, EAP re-authentication, etc.

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Sep 2006 13:39:42 -0400

I have a couple of terminology questions.

- When the term "pre-authentication" is used solely (instead of "EAP
pre-authentication"), does it mean EAP pre-authentication or something
else?

- The term "EAP re-authentication" is used without being defined.  It
may be good to define it.

- If re-keying is optimized such that EAP run is not required in its
signaling (but AAA interaction is needed), how should we call such a
scheme, re-authentication, non-EAP re-authentication, fast
re-authentication, etc.?

Yoshihiro Ohba

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 23 Sep 2006 04:22:43 -0700

In looking through the EAP Key Management Framework document, the term "EAP 
pre-authentication" is used in most cases; however, there are situations in 
which the term "pre-authentication" is used, when referring to EAP 
pre-authentication.  For the sake of clarity, I think it makes sense to 
change all uses to "EAP pre-authentication" as well as to define this term 
in the document.

How about this?

EAP pre-authentication
The use of EAP for the purposes of authenticating to a new authenticator 
while connected to a current authenticator.

The term "EAP re-authentication" is also used in the document, as is 
"re-authentication".  I would propose that all uses be described as "EAP 
re-authentication", and that this term also be defined.  How about this?

EAP re-authentication
The use of EAP to authenticate again to an authenticator to which the peer 
is connected.

Within the document, the term "re-key" is used if talking about the same 
authenticator; I don't believe that the use of the term "re-authentication" 
is used anywhere in the document (or in IEEE 802.11i for that matter) 
referring to this situation.  I believe IEEE 802.11r uses the term "fast 
transition" when moving between two authenticators.

>From: Yoshihiro Ohba <[email-masked]>
>To: [email-masked]
>Subject: [eap] EAP pre-authentication, EAP re-authentication, etc.
>Date: Fri, 22 Sep 2006 13:39:42 -0400
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 23 Sep 2006 04:29:06 -0700

Actually, I looked through the framework document, and found the following 
definition of EAP pre-authentication in Section 4:

EAP pre-authentication.  This utilizes EAP to pre-establish EAP
     keying material on an authenticator prior to arrival of the peer.

So how about this for the defintiion:

EAP  pre-authentication
The utilization of EAP to pre-establish EAP keying material on an 
authenticator prior to arrival of the peer.

>From: "Bernard Aboba" <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: Re: [eap] EAP pre-authentication, EAP re-authentication, etc.
>Date: Sat, 23 Sep 2006 04:22:43 -0700
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 23 Sep 2006 11:22:56 -0700

Hi Bernard,

Some notes inline:

>while connected to a current authenticator.

Your revised definition makes perfect sense here.  The key phrase 
being 'prior to' peer's handoff or attachment etc., to a new authenticator.

>The use of EAP to authenticate again to an authenticator to which the peer

The word Re-authentication is tricky.  As a stand-alone word, it is 
used to indicate "authenticating again."  But, 4187 uses it with the 
qualifier "fast"  and in that case described as "Fast 
re-authentication is based on the keys derived on the preceding
    full authentication."  Note that "authentication" or 
"re-authentication" has the qualifier "full" to avoid confusion.

In the EAP-ER draft, Vidya (Vidya, please chime in here) and I used 
the same line of reasoning of 4187; we further distinguish 
method-based "fast" re-authentication with method-independent 
"efficient" re-authentication.  The word "efficient" just indicates 
fewer roundtrips, nothing more.  We use the qualifier "full 
authentication" in the same sense of the phrase as in 4187.

Thus, efficient re-authentication or I'd venture to say that the word 
re-authentication itself, is defined as authenticating the peer to 
the network --EAP server to be precise -- using the keys derived on 
the preceding full authentication.  Note that pass-through 
authenticator may be same or different as the one involved in the 
full authentication.

>transition" when moving between two authenticators.

The definition for re-keying is quite clear: re-keying an SA may be 
defined as changing an active SA with a new SA, with the process 
being protected by the current SA (the SA being re-keyed) or the 
parent SA.  We might say something about the parties involved 
too.  In the context of unicast SAs, the parties to the re-keyed SA 
are the same as the parties to current SA.

EAP specifications use this in the context of TSK re-keying for 
instance and the definition fits well.

Thoughts?

Lakshminath

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 24 Sep 2006 00:05:24 +0300

> being 'prior to' peer's handoff or attachment etc., to a new
authenticator.

"Connection to an authenticator" needs some clarification though. In
pre-authentication, the peer is connected to the access network associated
with the serving authenticator, and it is authenticating with a target
authenticator that is associated with a target access network. 

> >The use of EAP to authenticate again to an authenticator to which the

Again, "being connected to an authenticator" is not clear. In this case, I
think it should be considered "re-authentication" if the peer had already
authenticated with the authenticator and still has valid (unexpired) keys
(MSK) with it. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 24 Sep 2006 20:31:04 -0400

Hi Lakshmith and Bernard,

> authenticator may be same or different as the one involved in the 

I think that whether the signaling is method-dependent or not is not
the fundamental difference between method-based "fast"
re-authentication and method-independent "efficient"
re-authentication.  The fundamental difference seems to be whether the
signaling results in re-keying of EAP keying material (MSK, EMSK,
TEKs) or not.  I think any method-based re-authentication requires
re-keying of EAP keying material while method-independent "efficient"
re-authentication does not.  Instead, method-independent "efficient"
re-authentication would require re-keying of a child key that is
derived from some intermediate key that is further derived from the
EAP keying material (when it is used for the serving authenticator) or
would require initial generation of a child key (not re-keying an
existing child key) from the intermediate key (when it is used for
target authenticators).

Also, it might be easier to understand to use the word
"authentication" in the EAP keying framework draft ONLY WHEN we talk
about any type of signaling that requires EAP run (e.g., EAP
pre-"authentication" and EAP re-"authentication").

Having said that, it might be good to call "method-independent
efficient re-authentication" something else (e.g., intermediate
keying).  I just feel confusing to use the word "authentication" for
it.

BTW, I don't much like the terms "fast" and "efficient" which are
ambigous in many cases.

> instance and the definition fits well.

EAP keying framework document uses the term "re-keying" not only for
TSK re-keying but also TEK re-keying.

Regards,
Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 24 Sep 2006 22:14:55 -0700

Hi Yoshi,
> > 
> 
> I think that whether the signaling is method-dependent or not 
> is not the fundamental difference between method-based "fast"
> re-authentication.  The fundamental difference seems to be 
> whether the signaling results in re-keying of EAP keying 
> material (MSK, EMSK,
> TEKs) or not.  I think any method-based re-authentication 
> requires re-keying of EAP keying material while 
> method-independent "efficient"
> re-authentication would require re-keying of a child key that 
> is derived from some intermediate key that is further derived 
> from the EAP keying material (when it is used for the serving 
> authenticator) or would require initial generation of a child 
> key (not re-keying an existing child key) from the 
> intermediate key (when it is used for target authenticators).
> 

Your observation is mostly correct. 

> "authentication" in the EAP keying framework draft ONLY WHEN 
> we talk about any type of signaling that requires EAP run 
> (e.g., EAP pre-"authentication" and EAP re-"authentication").
> 
> Having said that, it might be good to call 
> "method-independent efficient re-authentication" something 
> else (e.g., intermediate keying).  I just feel confusing to 
> use the word "authentication" for it.
> 

I don't quite agree with the above. Note that method independent
efficient re-authentication (as the method-specific ones) actually does
re-authenticate the peer by verifying proof of possession of keying
material generated from a previous EAP run. 

> BTW, I don't much like the terms "fast" and "efficient" which 
> are ambigous in many cases.
> 

I believe both method-specific and method-independent re-authentication
are in fact, re-authentication and re-keying. They re-key different
keying material, as you observe, but for the same purpose. It is just
that the adjective "fast" has history and "efficient" was chosen to
differentiate from that. I personally am okay with efficient, since the
goal is a single roundtrip protocol anyway - but, do you have other
suggestions in mind? 

Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Sep 2006 02:45:10 -0400

Hi Vidya,

On Sun, Sep 24, 2006 at 10:14:55PM -0700, Narayanan, Vidya wrote:
> are in fact, re-authentication and re-keying. 

When method-independent re-authentication is used for target
authenticators, it is not re-keying an existing SA.  Also, the peer
may be re-authenticating to an entity that holds the intermediate key,
but it is not *re*-authenticating to the target authenticators.

Having said that, when we use the term "(re-/pre-)authentication" it
may be very important to identify the fact that the target entity the
peer is (re-/pre-)authenticating to can be different depending on the
actual "(re-/pre-)authentication" scheme.  In the case of EAP
(re-/pre)-authentication, the target entity is always an authenticator
(serving or target).  In the case of method-specific
re-authentication, the target entity is always an EAP server.

> They re-key different

It appears that method-independent re-authentication (no "fast" or
efficient") mostly works for me, given that clear definition of what
target entity to which the peer re-authenticates as well as the
one-roundtrip requirement is provided.

What do you think?

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 24 Sep 2006 23:48:42 -0700

I would differentiate re-authentication and re-keying.  We can debate 
re-keying and the differences between re-authentication and re-keying 
later, but here let's talk about re-authentication.

Yoshi, it is understandable that you want to preserve the word 
authentication for full authentication.  At a first glance, I too 
thought that is better.  However, given the pass-through model and 
the use of that term in 4187, use of the word re-authentication in 
case of efficient re-authentication is apt.

Here is why: first, re-authentication, just as EAP full 
authentication, results in an MSK delivery to the pass-through 
authenticator.  The backed server uses a different process for 
authentication and a new rMSK derivation, but that's ok; as long as 
the parallels to the MSK derivation, and the use of EAP for 
authentication are present, it is EAP (re-)authentication.  Besides, 
4187 uses the terminology already: there fast re-authentication is 
defined as authentication "based on the keys derived on the preceding 
full authentication" as I quoted already.  I put together all this 
information and convinced myself that the word re-authentication 
fits.  Hope it's convincing to you too.  Inventing another term will 
only create unnecessary confusion.

best,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 24 Sep 2006 23:56:33 -0700

>TSK re-keying but also TEK re-keying.

Sure, but it seems like TEK re-keying also fits the definition I gave 
above.  I see that there is clear distinction between 
re-authentication and re-keying.  Do you see any ambiguity or 
similarity between the two?

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 25 Sep 2006 08:26:51 -0400

Hi Lakshminath,

On Sun, Sep 24, 2006 at 11:56:33PM -0700, Lakshminath Dondeti wrote:
> re-authentication and re-keying.  

I see.  Thank you for the clarification.

Yoshihiro Ohba

> Do you see any ambiguity or

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 25 Sep 2006 19:33:05 -0700

[BA]  While current EAP pre-authentication schemes require that the peer be 
connected to the same network (or even on the same VLAN) as the target 
authenticator, that doesn't necessarily have to be the case, right?

How about this?

EAP  pre-authentication

>EAP re-authentication
>The use of EAP to authenticate again to an authenticator to which the
>peer is connected.

[BA]   Interesting point.  Do we consider "EAP re-authentication" as having 
occurred when an EAP peer pre-authenticates to an authenticator with whom it 
had previously authenticated, even though it is not currently connected to 
it?  Does it matter if only the authenticator knows that this is occurring?

In the situation where the peer and authenticator are connected, they both 
know that the current keys are valid since they are using them to transmit 
data as well as re-authenticating.  However if the peer and authenticator 
are not currently exchanging data, they don't know whether they have 
currently valid keys, and so at least the peer may not be aware of whether 
it has valid keying material or not.  Do we consider "EAP re-authentication" 
to have occurred if a connection drops and the peer attempts to authenticate 
to the same authenticator?   Or when an EAP peer pre-authenticates to an 
authenticator with which it had previously established keying material 
(whether or not that keying material has expired or not, which the peer may 
not know).

How about this?

EAP re-authentication
The completion of EAP authentication between a peer and an authenticator 
with whom the EAP peer shares valid unexpired keying material.  Note that 
the EAP peer may not know whether previously established keying material is 
valid unless it has recently exchanged data with the authenticator, 
protected by TSKs derived from that keying material.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 27 Sep 2006 12:47:03 -0700

I am quite confused about this definitions of EAP re-authentication.
Assuming that we are not referring to method-specific fast
re-authentication, how is EAP re-authentication different from a regular
EAP exchange? 

Vidya 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, September 25, 2006 7:33 PM
> To: [email-masked]
> "Connection to an authenticator" needs some clarification 
> though. In pre-authentication, the peer is connected to the 
> access network associated with the serving authenticator, and 
> it is authenticating with a target authenticator that is 
> associated with a target access network.
> 
> [BA]  While current EAP pre-authentication schemes require 
> that the peer be connected to the same network (or even on 
> the same VLAN) as the target authenticator, that doesn't 
> necessarily have to be the case, right?
> 
> How about this?
> 
> EAP  pre-authentication
> The utilization of EAP to pre-establish EAP keying material 
> on an authenticator prior to arrival of the peer.
> 
> 
> >EAP re-authentication

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 28 Sep 2006 18:43:22 -0700

RFC 3748 defines Fast Reconnect as follows:

Fast reconnect
      The ability, in the case where a security association has been
      previously established, to create a new or refreshed security
      association more efficiently or in a smaller number of round-
      trips.

I think this may be what you are referring to as method-specific fast 
re-authentication.

EAP re-authentication as defined in the Key Management Framework document 
may or may not involve fast reconnect (for example, a given method may not 
support fast reconnect), but it always involves the exchange of EAP packets.

For example, rerun of the IEEE 802.11i 4-way handshake would constitute TSK 
re-key but it would not be described as "EAP re-authentication".

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 28 Sep 2006 19:25:08 -0700

> I think this may be what you are referring to as 
> method-specific fast re-authentication.
> 

I suppose. I'm guessing that the term Fast Reconnect is a common term
for things like Fast Re-authentication, Session Resumption, etc - is
that correct? 

> EAP re-authentication as defined in the Key Management 
> Framework document may or may not involve fast reconnect (for 
> example, a given method may not support fast reconnect), but 
> it always involves the exchange of EAP packets.
> 

When EAP re-authentication does not involve fast reconnect, what is it?
Is it any different from a full EAP exchange? 

Vidya

> For example, rerun of the IEEE 802.11i 4-way handshake would 
> constitute TSK re-key but it would not be described as "EAP 
> re-authentication".
> 
> >re-authentication, how is EAP re-authentication different from a 
> >regular EAP exchange?
> 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 1 Oct 2006 00:28:58 +0300

> authenticator, that doesn't necessarily have to be the case, right?

Yes, but that wasn't what I was thinking when writing that comment. I was
more concerned about the term: "connecting to an authenticator" which is not
defined yet afaik.

> authenticator prior to arrival of the peer.

"Connecting" and "arrival" are all about L1/L2 events, right? Those events
don't necessarily map to "using an EAP authenticator" one-to-one. So, how
about this?

EAP  pre-authentication
The utilization of EAP to pre-establish EAP keying material on an
authenticator prior to arrival of the peer at the access network managed by
that authenticator.

> it?  

I'd think so. 

> Does it matter if only the authenticator knows that this is
> occurring?

It may matter for a solution that tries to utilize re-authentication cases.

> it has valid keying material or not.  

Peer would know that if it can identify the authenticator. For example, in
PANA, the PaC (EAP peer) knows the PAA identity. 

> Do we consider "EAP re-
> authentication"
> to the same authenticator?  

I'd think so.

> Or when an EAP peer pre-authenticates to an

I think it'd not be a re-authentication if the keys have expired. 

I'm assuming we are defining re-authentication (with respect to an
authenticator) to take advantage of that when possible. If there is no
keying material or any other state left on an authenticator for a given
peer, is there any optimization we can do?

> with whom the EAP peer shares valid unexpired keying material.  

Yes.

> Note that

Hmmm.... This is tricky. In the absence of explicit authenticator
identifiers, even if the host (peer) is using the same connection to the
access network, it cannot know the same authenticator is used. Things like
authenticator relocation can happen transparent to the peer. 

Alper