EAP pre-authentication, EAP re-authentication, etc.

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

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 <yohbatari.toshiba.com>
>To: eapfrascone.com
>Subject: [eap] EAP pre-authentication, EAP
re-authentication, etc.
>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


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

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

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" <bernard_abobahotmail.com>
>To: yohbatari.toshiba.com, eapfrascone.com
>Subject: Re: [eap] EAP pre-authentication, EAP
re-authentication, etc.
>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 <yohbatari.toshiba.com>
> >To: eapfrascone.com
> >Subject: [eap] EAP pre-authentication, EAP
re-authentication, etc.
> >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
>
>
>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap


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

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

Hi Bernard,

Some notes inline:

At 04:22 AM 9/23/2006, Bernard Aboba wrote:
>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.

Your revised definition makes perfect sense here.  The key
phrase 
being 'prior to' peer's handoff or attachment etc., to a
new 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.

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.


>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.

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: Yoshihiro Ohba <yohbatari.toshiba.com>
> >To: eapfrascone.com
> >Subject: [eap] EAP pre-authentication, EAP
re-authentication, etc.
> >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
>
>
>________________________________________________________
_________
>To unsubscribe or modify your subscription options,
please visit:
>http:/
/lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.
frascone.com/pipermail/eap

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

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

> >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.
> 
> Your revised definition makes perfect sense here.  The
key phrase
> 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 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.

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



> 
> 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.
> 
> 
> >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.
> 
> 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: Yoshihiro Ohba <yohbatari.toshiba.com>
> > >To: eapfrascone.com
> > >Subject: [eap] EAP pre-authentication, EAP
re-authentication, etc.
> > >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
> >
> >
>
>________________________________________________________
_________
> >To unsubscribe or modify your subscription options,
please visit:
> >http:/
/lists.frascone.com/mailman/listinfo/eap
> >
> >Arhives: http://lists.
frascone.com/pipermail/eap
> 
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> http:/
/lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.
frascone.com/pipermail/eap

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

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

Hi Lakshmith and Bernard,

On Sat, Sep 23, 2006 at 11:22:56AM -0700, Lakshminath
Dondeti wrote:
> Hi Bernard,
> 
> Some notes inline:
> 
> At 04:22 AM 9/23/2006, Bernard Aboba wrote:
> >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.
> 
> Your revised definition makes perfect sense here.  The
key phrase 
> being 'prior to' peer's handoff or attachment etc.,
to a new 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.
> 
> 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.
> 

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.

> 
> >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.
> 
> 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.

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

Regards,
Yoshihiro Ohba

> 
> Thoughts?
> 
> Lakshminath
> 
> 
> 
> 
> 
> >>From: Yoshihiro Ohba <yohbatari.toshiba.com>
> >>To: eapfrascone.com
> >>Subject: [eap] EAP pre-authentication, EAP
re-authentication, etc.
> >>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
> >
> >
>
>________________________________________________________
_________
> >To unsubscribe or modify your subscription options,
please visit:
> >http:/
/lists.frascone.com/mailman/listinfo/eap
> >
> >Arhives: http://lists.
frascone.com/pipermail/eap
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

Hi Yoshi,
> > 
> 
> 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).
> 

Your observation is mostly correct. 

> 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.
> 

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
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

Hi Vidya,

On Sun, Sep 24, 2006 at 10:14:55PM -0700, Narayanan, Vidya
wrote:
> Hi Yoshi,
> > > 
> > 
> > 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).
> > 
> 
> Your observation is mostly correct. 
> 
> > 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.
> > 
> 
> 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. 

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
> 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? 

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

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

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

At 05:31 PM 9/24/2006, Yoshihiro Ohba wrote:
> > >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.
> >
> > 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.
>
>EAP keying framework document uses the term
"re-keying" not only for
>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


>Regards,
>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

Hi Lakshminath,

On Sun, Sep 24, 2006 at 11:56:33PM -0700, Lakshminath
Dondeti wrote:
> At 05:31 PM 9/24/2006, Yoshihiro Ohba wrote:
> >> >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.
> >>
> >> 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.
> >
> >EAP keying framework document uses the term
"re-keying" not only for
> >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.  

I see.  Thank you for the clarification.

Yoshihiro Ohba


> Do you see any ambiguity or 
> similarity between the two?



> 
> regards,
> Lakshminath
> 
> 
> >Regards,
> >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