Subject: [HOKEY] WGLC - draft-ietf-hokey-preauth-ps-07

From: "Glen Zorn" <[email-masked]>
Date: Fri, 5 Jun 2009 10:22:36 +0700

This message announces the beginning of Working Group Last Call on
draft-ietf-hokey-preauth-ps-07
(http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-07.txt) .
The last call comment period will end on Friday, 19 June 2009 at 04:00 GMT.
When submitting comments on the draft, please respond to this message,
leaving the Subject: line intact.  Thank you.

~gwz

Play assigns meaning to human activity--work erases it.
  -- P.L. Wilson

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Fri, 5 Jun 2009 13:31:28 +0900

Hi, all.

I've been following this document. It is in a good shape and ready to be
progressed.

Cheers.

On Fri, Jun 5, 2009 at 12:22 PM, Glen Zorn <[email-masked]> wrote:

> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://hurryon.googlepages.com/

---

From: Katrin Höper <[email-masked]>
Date: Wed, 10 Jun 2009 18:50:56 -0500

Hi,

I am glad seeing this draft finally moving forward. While I believe that
most technical issues have been resolved in the latest version, the draft
still needs major editorial revisions. In its current state, the draft is
barely readable and readers need to do a lot of guessing to understand some
of the technical discussions.

With three editors, one of them being a native speaker, it should be
possible to polish the language and remove the ambiguity in some
descriptions. I am addressing many editorial issues that I noticed while
reading the draft in my review below. However, my list is far from being
exhaustive and I urge the editors to review their draft one more time to
clean up the language and presentation.

Best regards,
Katrin

General comments:

1) The problem statement is valid for general wireless technologies;
however, a lot of IEEE 802.11-specific terminology is defined in Section 2.
While it is OK to use .11 networks as an example to illustrate some
mechanisms or protocol steps, it is unnecessary to define .11 terminology in
Section 2.

2) The differentiation between intra-authenticator and inter-authenticator
handovers seems unnecessary. No example scenarios for intra-authenticator
handovers are provided in the draft, and frankly I don’t see any. Since
intra-authenticator handovers are not covered by any of the usage models, I
suggest removing this notion altogether and assume that all handovers are
between different authenticators in the document. In that case
inter-authenticator HOs do not need to be explicitly defined either.

3) The problem statement (Section 3) is too long with over 4 pages text and
covers far more than just the problem statement!

I suggest breaking the text into several sections: Section 3 “Problem
statement” until page 7 without last paragraph, Section 4 “System overview”
and Section 5 “Topological Classifications of handover Scenarios” (now
Section 3.1). Alternatively Section 3.1 and 4 could be merged.

4) Inconsistency in used terminology. Many (partially unnecessary) terms are
defined Section 3, but then numerous other –undefined, yet important- terms
are used throughout the document. For example, an 802.11 access point is
defined, while the technology-independent term point of attachment is not
defined. In addition, point of access is used several times. This can lead
to a lot of guessing when one tries to understand some of the technical
discussions.

Specific comments/nits

Section 1,

first paragraph

*) typo+acronym : “…has a tolerable packet (SDU) rates ranging” -> “…has a
tolerable Service Data Units (SDU) rate ranging”

*)can you provide a reference for the tolerable error rates and delays for
streaming applications?

between first and second paragraph

add a comment on re-authentication here. Basically the stated goals also
apply to re-authentication, which already has a solution (ERP) in HOKEY.
This should be stated here, together with a brief overview of the
differences between pre-authentication and re-authentication (e.g. different
use cases)

second paragraph

delete second “because of” in first sentence.

third paragraph, last sentence

Isn’t this sentence too general? Early authentication as discussed in this
draft aims to reduce the delay of EAP-based network-access authentication
and authorization during handovers.

Section 2

*) AAA: This definition does not use real sentences. Please revise,

*) Access Point (AP): delete (see general comment #1)

*) Authenticator: Please repeat the definition and then reference.

*) Basic Servive Set (BSS): delete (see general comment #1)

*) EAP Server: Please repeat the definition and then reference.

*) EAP Early Authentication: rephrase for better readability, e.g.

Change “The utilization of EAP to pre-establish EAP keying material on an
EAP authenticator prior to arrival on a link served by that authenticator of
the mobile device that acts as an EAP peer.” to “The utilization of EAP to
pre-establish EAP keying material on a candidate EAP authenticator, i.e.  prior
to a peer’s arrival on a link served by that authenticator.

*) ESS: delete (see general comment #1)

*) Inter-Authenticator Handover: delete (see general comment #2)

*) Inter-ESS Handover: delete (see general comment #1)

*) Intra-AAA-Domain Handover (Intra-Domain Handover):

typo: change “Intra-AAA-domain handover include a handover across different
authenticators within the same AAA domain.” to “Intra-AAA-domain handovers
include handovers across different authenticators within the same AAA
domain.”

*) MSK: Please repeat the definition and then reference.

*) Peer: remove “(below)” and please revise this definition.

*) Target Access Network: change “chosen” to “selected”

*) Target Authenticator: change “chosen” to “selected”

*) Add definition for “Point of attachment”

Section 3

second line: change “iand” to “and”

second paragraph

*) “candidate network points of attachment” is a term not defined. Can you
use a term that is actually defined, such as target authenticator? If not
add “candidate Point of Attachment” to definitions.

*) Change “Handover execution consists of setting up L2 and L3 connectivity
with the target.” to “Handover execution consists of setting up L2- and
L3-connectivity with the target network.”

*) “link-layer ciphering keys”, this term is not commonly used and also not
defined, suggest using cipher keys or encryption keys

*) Change “Hence, improvement in the handover latency performance due to EAP
is a    necessary objective for such scenarios.” to “Hence, improvement of
the handover latency performance caused by EAP is a necessary objective for
such scenarios.”

fourth paragraph

Change “As another example, in 3GPP Technical Specification TS 33.402
[TS33.402]], network access authentication and authorization happens after
L2 connection is established between the mobile device and a non-3GPP target
access network, and involves EAP exchange between the mobile device and 3GPP
AAA server through the non-3GPP target access network.” to “As another
example, in 3GPP Technical Specification TS 33.402 [TS33.402], network
access authentication and authorization occurs after a L2 connection is
established between the mobile device and a non-3GPP target access network.
This involves EAP exchange between the mobile device and 3GPP AAA server
through the non-3GPP target access network.”

fifth paragraph

*) Consistency:  “The work done in the IEEE 802.11f ([IEEE.802-11F.2003] and
802.11r [IEEE.802-11R.2008]) Task Groups applies only to transfers within
one 802.11 ESS or AAA domain.” Use your own definitions, e.g.
intra-technology and intra-AAA domain handover.

*) “not really” is not proper scientific language

sixth paragraph

*) rephrase: “can be seen” is awkward, what about: “Two classes of optimized
solutions for secure handovers can be distinguished: 1) security context
transfer…and 2) early authentication. “

*) Consistency: Change “new point of attachment” to “candidate point of
attachement”

*) “home realm” and “visited domain” have not been defined, please use
defined terms or add definitions.

*) change “cryptologically independent re-authentication key” to
“cryptographically independent re-authentication key”

seventh paragraph

suggest changing

“However, there are certain cases where ERP is not applicable or an
additional optimization mechanism is needed to establish a key for the
candidate authenticator:

   o  One case is an inter-domain handover.  A trust relationship is
required between the home and visited AAA domains.  Given that trust
relationship and assuming the visited AAA domain supports ERP, full EAP
authentication with the EAP server in the home AAA domain is still needed to
distribute the existing keying materials to the ERP server when the mobile
device first enters the visited AAA domain.

   o  Another case is an inter-technology handover where the candidate and
serving authenticator are different entities belonging to two different
visited AAA domains and the AAA is same in the home AAA domain.”

to

“However, there are certain cases where ERP is not applicable or an
additional optimization mechanism is needed to establish a key for a
candidate authenticator:

   o  Inter-domain handover.  Here, a trust relationship is required between
the home and visited AAA domains, e.g. in form of roaming agreements.
Assuming that such a relationship exists and the visited AAA domain supports
ERP, full EAP authentication with the EAP server in the home AAA domain is
still needed to distribute the existing keying materials to the ERP server
when the mobile device first enters the visited AAA domain.

o  Inter-technology handover. ERP is not applicable in inter-technology
handovers in which candidate and serving authenticators are located in two
different visited AAA domains.”

After seventh paragraph

add sentence that Early authentication is applicable in scenarios where ERP
is not applicable.

eighth paragraph

change “The goal of EAP early authentication is to complete AAA signaling
for

EAP before the peer moves.”

to

“The goal of EAP early authentication is to complete AAA signaling for EAP
before the peer moves to a candidate network”.

ninth paragraph:

*) start new section, e.g. “System overview” (see general comment #3)

*) text and Figure should reflect that there can be multiple candidate
authenticators

Section 3.1

*) should be own section or merged with Section 4 (see general comment #3)

*) remove handover scenario 1 “intra-authenticator handover”, (see general
comment #2)

*) 2 a) change “lie within the same network” to “are located in the same
network”

*) 2 b) change “a AAA server” to “an AAA server”

*) create a bullet for the “fourth case”

*) change “thinking of the link technology involved” to “ with respect to
the link technology involved”

Section 4

first paragraph

*) Change “This section concentrates on providing some usage models around
which we can build our analysis of the EAP early authentication problem.”

to

“This section defines some usage for our analysis of the EAP early
authentication problem.”

last paragraph before Section 4.1

*) “It is assumed that the serving and candidate authenticators are
different entities (case 1 of Section 3.1 excluded). “ this is another
reason why “intra-authenticator handovers should be entirely removed from
this draft.

Section 4.1.1

*) explain: “or there may be no serving authenticator at all in the serving
access network.” When is this the case?  Do you have an example?

*) Figure 2 is not referenced at all. Please add reference and some
explanation

*) Fix awkward line-breaking in Figure 2, i.e. “EAP Auth-enticator” to “EAP
-> Authenticator”

*) revise caption of Figure 3, e.g. from “Figure 3: Direct
Pre-authentication Signaling for the Usage Model” to “Figure 3: Signaling
Diagram for Direct Pre-authentication”

Section 4.1.2

*) add period after first sentence

*) Fix awkward line-breaking in Figure 4, i.e. “EAP Auth-enticator” to “EAP
-> Authenticator”

*) Change “In this indirect pre-authentication model, it is assumed that a
trust    relationship exists between the serving network (or serving AAA
domain) and candidate network (or candidate AAA domain).”

to

“In the indirect pre-authentication model, it is assumed that a trust
relationship exists between the serving network (or serving AAA domain) and
the candidate network (or candidate AAA domain).”

*) a second implicit assumption for this model should be mentioned here,
namely that the SA and CA can directly communicate with each other.

*) Change “This pre-authentication model is needed if the peer cannot
discover the candidate authenticator's Identity or if IP communication is
not available due to security or network topology reasons.”

to

“This pre-authentication model is needed if a peer cannot discover the
identifiers of candidate authenticators or if communications at the IP-layer
are not available due to security or network topology reasons.”

*) Change “The role of the serving authenticator in this pre-authentication
model is to forward EAP pre-authentication signaling between the peer and
candidate authenticator and not to act as an authenticator for the candidate
point of access.  It continues to act as an authenticator for the serving
point of access. The role of the candidate authenticator is to forward EAP
pre-authentication signaling between the peer (via the serving
authenticator) and EAP server and receive the transported keying materials
from the EAP

server as an authenticator.”

to

“The role of the serving authenticator in this pre-authentication model is
to simply forward EAP pre-authentication signaling between the peer and
candidate authenticator. In addition, the SA continues to act as an
authenticator for the serving point of attachment. The role of the candidate
authenticator is to forward EAP pre-authentication signaling between the
peer (via the serving authenticator) and EAP server. Upon a successful EAP
execution, the EAP server transports some of the derived keying material to
the candidate authenticator.”

*) Change caption of Figure 5, e.g. “to “Figure 5: Signaling Diagram for
Indirect Pre-authentication”

*) Merge two last sentences and remove line breaks.

Section 4.2

*) Why is there no signaling diagram as for the other two usage models?

*) Change “In this usage model, it is assumed that there is no trust
relationship between the serving authenticator and the candidate
authenticator.  The serving authenticator is involved in EAP authenticated
anticipatory keying signaling.”

to

“This usage model does not assume a pre-existing trust relationship between
the serving authenticator and the candidate authenticator. Only the serving
authenticator is involved in EAP authenticated anticipatory keying
signaling.”

*) Change “This is not the simple mediation function of an authenticator,
because the SA-AAA signaling in this case must identify the candidate
authenticator to which keying material must be pushed.  The role of the
candidate authenticator is to receive the transported keying materials from
the EAP server and to act as an authenticator after handover occurs.”

to

“This is not the simple mediation function of an authenticator, because the
SA-AAA signaling must identify the candidate authenticator to which keying
material should be pushed after a successful EAP execution.  After the
keying material has been transported to the candidate authenticator, the
candidate authenticator is ready to serve as the target authenticator after
a handover occurs.”

Section 5.1

Is this relevant? It seems that all examples suggest that authenticator
discovery is specified in a separate protocol. If not, please provide
examples.

Section 5.2

*) general: you continuously use “normal authentication” in the remainder of
the draft. This is not a good term. Before you have used “full (EAP)
authentication”, which is a better term. Also “conventional  authentication”
is better.

*) rephrase “context binding needs to be securely made”

Section 6

*) change “Most of the AAA documents today do not distinguish between a
normal    authentication and a early authentication and this creates a set
of open issues:”

to

“Most of the AAA documents today do not distinguish between a full
authentication and an early authentication which leads to some open issues:”

 *) Early authentication lifetime: fix some typos, “normal” -> full, “a
early authentication” -> “an early authentication”, “a AAA server” -> “an
AAA server”

*) Early authentication retries: “(the procedure for which is not the topic
of this particular subsection).” This is not the topic of this paragraph or
out of scope of the draft? If it is in the scope of this draft, please
reference to the part where this problem is discussed,

*) Early authentication retries: change “However, if the peer has not yet
moved to the new location and realizes that the early authentication is
expiring, it may perform another early authentication.  Some limiting
mechanism is needed to avoid an unlimited number of early-authentication
attempts.”

to

“However, if a peer has not yet moved to the new location and the early
authentication is about to expire, the peer may perform another early
authentication.  Some mechanism is needed to limit the number of
early-authentication attempts.”

*) Multiple candidate authenticators: First sentence needs to be fixed

*) Multiple candidate authenticators: “This amplifies the difficulties noted
under the point "Early authentication authorization"”. Does this paragraph
have any other implications? If not, can be added to first bullet “Early
authentication authorization”. If yes, please indicate what.

*) Inter-domain handover support: what is an “early authentication key”?
This has not been defined anywhere. What about “…required by both the peer
and the authenticator for deriving keying material needed for mutual
authentication….”

Section 7

*)”non-cryptographic packet”, what is this? Need to revise this sentence.

*) change “In addition, a simple solution for the peer side would be to let
the peer always initiate EAP early authentication and not allow EAP early
authentication initiation from an authenticator.”

to

“In addition, a simple solution for the peer side would be to let the peer
always initiate EAP early authentication and not allow EAP early
authentication to be initiated by an authenticator.”

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Jun 2009 18:55:36 +0700

Reminder: the last call comment period will end on Friday, 19 June 2009 at
04:00 GMT.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 19 Jun 2009 10:18:16 +0200

Dear all,

My apologies if I am arriving a little bit late. I agree with Katrin's 
detailed review. I have two additional comments.

In section 4.2

"The role of the serving authenticator in this usage model is to
communicate with the peer on one side and exchange authenticated
anticipatory keying signaling with the EAP server on the other side.
This is not the simple mediation function of an authenticator,
because the SA-AAA signaling in this case must identify the candidate
authenticator to which keying material must be pushed. The role of
the candidate authenticator is to receive the transported keying
materials from the EAP server and to act as an authenticator after
handover occurs. The Peer-SA signaling is performed over L2 or L3.
The SA-AAA and AAA-CA segments operate over L3."

Not sure if I understand this line: "the SA-AAA signaling in this case 
must identify the candidate authenticator to which keying material must 
be pushed". Does it mean that the AAA protocol needs to carry 
information about the authenticators where keys should be pushed?. I 
thought that information should be included in the EAP signalling 
between peer and server in this model.

In section 7. Security Considerations, it seems that security 
considerations are only associated to EAP pre-authentication model but I 
failed to see something related with authenticated anticipatory keying 
usage model.

Btw, after reading some previous e-mails... I would also vote to use the 
terms serving NAS and candidate NAS in the I-D.

Just my 2 cents.

Katrin Höper wrote:
>
> Hi,
>
> I am glad seeing this draft finally moving forward. While I believe 
> that most technical issues have been resolved in the latest version, 
> the draft still needs major editorial revisions. In its current state, 
> the draft is barely readable and readers need to do a lot of guessing 
> to understand some of the technical discussions.
>
> descriptions. I am addressing many editorial issues that I noticed 
> while reading the draft in my review below. However, my list is far 
> from being exhaustive and I urge the editors to review their draft one 
> more time to clean up the language and presentation.
> Best regards,
> Katrin
>
> General comments:
>
> however, a lot of IEEE 802.11-specific terminology is defined in 
> Section 2. While it is OK to use .11 networks as an example to 
> illustrate some mechanisms or protocol steps, it is unnecessary to 
> define .11 terminology in Section 2.
>
> 2) The differentiation between intra-authenticator and 
> inter-authenticator handovers seems unnecessary. No example scenarios 
> for intra-authenticator handovers are provided in the draft, and 
> frankly I don’t see any. Since intra-authenticator handovers are not 
> covered by any of the usage models, I suggest removing this notion 
> altogether and assume that all handovers are between different 
> authenticators in the document. In that case inter-authenticator HOs 
> do not need to be explicitly defined either.
>
> 3) The problem statement (Section 3) is too long with over 4 pages 
> text and covers far more than just the problem statement!
>
> statement” until page 7 without last paragraph, Section 4 “System 
> overview” and Section 5 “Topological Classifications of handover 
> Scenarios” (now Section 3.1). Alternatively Section 3.1 and 4 could be 
> merged.
>
> 4) Inconsistency in used terminology. Many (partially unnecessary) 
> terms are defined Section 3, but then numerous other –undefined, yet 
> important- terms are used throughout the document. For example, an 
> 802.11 access point is defined, while the technology-independent term 
> point of attachment is not defined. In addition, point of access is 
> used several times. This can lead to a lot of guessing when one tries 
> to understand some of the technical discussions.
>
> Specific comments/nits
>
> Section 1,
>
> first paragraph
>
> *) typo+acronym : “…has a tolerable packet (SDU) rates ranging” -> 
> “…has a tolerable Service Data Units (SDU) rate ranging”
>
> *)can you provide a reference for the tolerable error rates and delays 
> for streaming applications?
>
> add a comment on re-authentication here. Basically the stated goals 
> also apply to re-authentication, which already has a solution (ERP) in 
> HOKEY. This should be stated here, together with a brief overview of 
> the differences between pre-authentication and re-authentication (e.g. 
> different use cases)
>
> second paragraph
>
> Isn’t this sentence too general? Early authentication as discussed in 
> this draft aims to reduce the delay of EAP-based network-access 
> authentication and authorization during handovers.
>
> Section 2
>
> Change “The utilization of EAP to pre-establish EAP keying material on 
> an EAP authenticator prior to arrival on a link served by that 
> authenticator of the mobile device that acts as an EAP peer.” to “The 
> utilization of EAP to pre-establish EAP keying material on a candidate 
> EAP authenticator, i.e. prior to a peer’s arrival on a link served by 
> that authenticator.
>
> typo: change “Intra-AAA-domain handover include a handover across 
> different authenticators within the same AAA domain.” to 
> “Intra-AAA-domain handovers include handovers across different 
> authenticators within the same AAA domain.”
>
> *) “candidate network points of attachment” is a term not defined. Can 
> you use a term that is actually defined, such as target authenticator? 
> If not add “candidate Point of Attachment” to definitions.
>
> *) Change “Handover execution consists of setting up L2 and L3 
> connectivity with the target.” to “Handover execution consists of 
> setting up L2- and L3-connectivity with the target network.”
>
> *) “link-layer ciphering keys”, this term is not commonly used and 
> also not defined, suggest using cipher keys or encryption keys
>
> *) Change “Hence, improvement in the handover latency performance due 
> to EAP is a necessary objective for such scenarios.” to “Hence, 
> improvement of the handover latency performance caused by EAP is a 
> necessary objective for such scenarios.”
>
> fourth paragraph
>
> [TS33.402]], network access authentication and authorization happens 
> after L2 connection is established between the mobile device and a 
> non-3GPP target access network, and involves EAP exchange between the 
> mobile device and 3GPP AAA server through the non-3GPP target access 
> network.” to “As another example, in 3GPP Technical Specification TS 
> 33.402 [TS33.402], network access authentication and authorization 
> occurs after a L2 connection is established between the mobile device 
> and a non-3GPP target access network. This involves EAP exchange 
> between the mobile device and 3GPP AAA server through the non-3GPP 
> target access network.”
>
> fifth paragraph
>
> *) Consistency: “The work done in the IEEE 802.11f 
> ([IEEE.802-11F.2003] and 802.11r [IEEE.802-11R.2008]) Task Groups 
> applies only to transfers within one 802.11 ESS or AAA domain.” Use 
> your own definitions, e.g. intra-technology and intra-AAA domain handover.
>
> *) rephrase: “can be seen” is awkward, what about: “Two classes of 
> optimized solutions for secure handovers can be distinguished: 1) 
> security context transfer…and 2) early authentication. “
>
> *) Consistency: Change “new point of attachment” to “candidate point 
> of attachement”
>
> relationship and assuming the visited AAA domain supports ERP, full 
> EAP authentication with the EAP server in the home AAA domain is still 
> needed to distribute the existing keying materials to the ERP server 
> serving authenticator are different entities belonging to two 
> different visited AAA domains and the AAA is same in the home AAA domain.”
>
> to
>
> o Inter-domain handover. Here, a trust relationship is required 
> between the home and visited AAA domains, e.g. in form of roaming 
> agreements. Assuming that such a relationship exists and the visited 
> AAA domain supports ERP, full EAP authentication with the EAP server 
> in the home AAA domain is still needed to distribute the existing 
> keying materials to the ERP server when the mobile device first enters 
> the visited AAA domain.
>
> handovers in which candidate and serving authenticators are located in 
> two different visited AAA domains.”
>
> After seventh paragraph
>
> add sentence that Early authentication is applicable in scenarios 
> where ERP is not applicable.
>
> eighth paragraph
>
> change “The goal of EAP early authentication is to complete AAA 
> signaling for
>
> “The goal of EAP early authentication is to complete AAA signaling for 
> EAP before the peer moves to a candidate network”.
>
> ninth paragraph:
>
> *) remove handover scenario 1 “intra-authenticator handover”, (see 
> general comment #2)
>
> *) 2 a) change “lie within the same network” to “are located in the 
> same network”
>
> *) change “thinking of the link technology involved” to “ with respect 
> to the link technology involved”
>
> Section 4
>
> first paragraph
>
> *) Change “This section concentrates on providing some usage models 
> around which we can build our analysis of the EAP early authentication 
> problem.”
>
> to
>
> reason why “intra-authenticator handovers should be entirely removed 
> from this draft.
>
> Section 4.1.1
>
> *) explain: “or there may be no serving authenticator at all in the 
> serving access network.” When is this the case? Do you have an example?
>
> *) Fix awkward line-breaking in Figure 2, i.e. “EAP Auth-enticator” to 
> “EAP -> Authenticator”
>
> Pre-authentication Signaling for the Usage Model” to “Figure 3: 
> Signaling Diagram for Direct Pre-authentication”
>
> Section 4.1.2
>
> *) Fix awkward line-breaking in Figure 4, i.e. “EAP Auth-enticator” to 
> “EAP -> Authenticator”
>
> *) Change “In this indirect pre-authentication model, it is assumed 
> that a trust relationship exists between the serving network (or 
> serving AAA domain) and candidate network (or candidate AAA domain).”
>
> to
>
> relationship exists between the serving network (or serving AAA 
> domain) and the candidate network (or candidate AAA domain).”
>
> *) a second implicit assumption for this model should be mentioned 
> here, namely that the SA and CA can directly communicate with each other.
>
> discover the candidate authenticator's Identity or if IP communication 
> is not available due to security or network topology reasons.”
>
> to
>
> identifiers of candidate authenticators or if communications at the 
> IP-layer are not available due to security or network topology reasons.”
>
> *) Change “The role of the serving authenticator in this 
> pre-authentication model is to forward EAP pre-authentication 
> signaling between the peer and candidate authenticator and not to act 
> as an authenticator for the candidate point of access. It continues to 
> act as an authenticator for the serving point of access. The role of 
> the candidate authenticator is to forward EAP pre-authentication 
> signaling between the peer (via the serving authenticator) and EAP 
> server and receive the transported keying materials from the EAP
>
> “The role of the serving authenticator in this pre-authentication 
> model is to simply forward EAP pre-authentication signaling between 
> the peer and candidate authenticator. In addition, the SA continues to 
> act as an authenticator for the serving point of attachment. The role 
> of the candidate authenticator is to forward EAP pre-authentication 
> signaling between the peer (via the serving authenticator) and EAP 
> server. Upon a successful EAP execution, the EAP server transports 
> some of the derived keying material to the candidate authenticator.”
>
> *) Change caption of Figure 5, e.g. “to “Figure 5: Signaling Diagram 
> for Indirect Pre-authentication”
>
> authenticator. The serving authenticator is involved in EAP 
> authenticated anticipatory keying signaling.”
>
> to
>
> “This usage model does not assume a pre-existing trust relationship 
> between the serving authenticator and the candidate authenticator. 
> Only the serving authenticator is involved in EAP authenticated 
> *) Change “This is not the simple mediation function of an 
> authenticator, because the SA-AAA signaling in this case must identify 
> the candidate authenticator to which keying material must be pushed. 
> The role of the candidate authenticator is to receive the transported 
> keying materials from the EAP server and to act as an authenticator 
> after handover occurs.”
>
> to
>
> “This is not the simple mediation function of an authenticator, 
> because the SA-AAA signaling must identify the candidate authenticator 
> to which keying material should be pushed after a successful EAP 
> execution. After the keying material has been transported to the 
> candidate authenticator, the candidate authenticator is ready to serve 
> as the target authenticator after a handover occurs.”
>
> Section 5.1
>
> Is this relevant? It seems that all examples suggest that 
> authenticator discovery is specified in a separate protocol. If not, 
> please provide examples.
>
> Section 5.2
>
> *) general: you continuously use “normal authentication” in the 
> remainder of the draft. This is not a good term. Before you have used 
> “full (EAP) authentication”, which is a better term. Also 
> “conventional authentication” is better.
>
> *) change “Most of the AAA documents today do not distinguish between 
> a normal authentication and a early authentication and this creates a 
> set of open issues:”
>
> to
>
> early authentication” -> “an early authentication”, “a AAA server” -> 
> “an AAA server”
>
> *) Early authentication retries: “(the procedure for which is not the 
> topic of this particular subsection).” This is not the topic of this 
> paragraph or out of scope of the draft? If it is in the scope of this 
> draft, please reference to the part where this problem is discussed,
>
> *) Early authentication retries: change “However, if the peer has not 
> yet moved to the new location and realizes that the early 
> authentication is expiring, it may perform another early 
> authentication. Some limiting mechanism is needed to avoid an 
> unlimited number of early-authentication attempts.”
>
> to
>
> “However, if a peer has not yet moved to the new location and the 
> early authentication is about to expire, the peer may perform another 
> early authentication. Some mechanism is needed to limit the number of 
> *) Multiple candidate authenticators: “This amplifies the difficulties 
> noted under the point "Early authentication authorization"”. Does this 
> paragraph have any other implications? If not, can be added to first 
> bullet “Early authentication authorization”. If yes, please indicate what.
>
> *) Inter-domain handover support: what is an “early authentication 
> key”? This has not been defined anywhere. What about “…required by 
> both the peer and the authenticator for deriving keying material 
> needed for mutual authentication….”
>
> Section 7
>
> *) change “In addition, a simple solution for the peer side would be 
> to let the peer always initiate EAP early authentication and not allow 
> EAP early authentication initiation from an authenticator.”
>
> to
>
> “In addition, a simple solution for the peer side would be to let the 
> peer always initiate EAP early authentication and not allow EAP early 
> On Thu, Jun 4, 2009 at 10:22 PM, Glen Zorn <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Jun 2009 15:29:23 +0700

GENERAL COMMENTS

This document consistently uses the term "authenticator" to mean something
other than an EAP authenticator; it begins in the Abstract and just goes on
& on.  For example, the Abstract says:
   EAP (Extensible Authentication Protocol) early authentication may be
   defined as the use of EAP to establish authenticated keying material
   on a target authenticator prior to arrival of the peer at the access
   network managed by that authenticator.
Unfortunately, EAP authenticators don't receive keying material, nor do the
"manage networks"; not even 802.11 can be said to do the latter.  The
"authenticator" in this draft appears to be some amalgam of whatever
functionality is useful for the task at hand, including AAA client
functions, cryptographic traffic protection and others, as well as EAP
support.  Another example, from Section 1: "The discussion in this document
is focused on mitigating delay due to network access authentication and
authorization."  Optimizing authentication doesn't necessarily speed
authorization, since the two functions are provided by different protocols
(at least in the case of EAP, which is the only one relevant here).  I
realize that it has become popular to conflate EAP & AAA, but that is not
just technically incorrect, but dangerous: sloppy thinking only leads to
sloppier thinking, eventually leading to very poor standards.  So, what I
want to recommend is this: add another definition to the Terminology section
defining an entity that actually does the things that we're currently
imputing to the poor authenticator.  Here is some suggested text:

Network Access Server (NAS)
	A device, such as a wireless access point, that serves as a gateway
between
	access clients and a network.  In the context of this document, a
NAS must
	also support EAP authenticator functionality and may act as a AAA
client.

Then, I recommend replacing the word "authenticator" in the terms  "target
authenticator", "serving authenticator" and "candidate authenticator" to
"NAS" everywhere in the document.  BTW, I'm not married to the term "NAS";
anything will do (except "Access Point" ;-), but I do think that the
definition makes sense.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Jun 2009 20:08:21 +0700

Rafa Marin Lopez [mailto://[email-masked]] writes:

> Dear all,
> 
> My apologies if I am arriving a little bit late. 

No problem; I actually had intended to (& thought that I had!) set the
deadline for 4:00 PM (16:00) GMT.  Since I made that mistake (& since my own
comments aren't complete because of it ;-), I'm extending the deadline by 24
hours, until 04:00 tomorrow, 20 June.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Jun 2009 21:12:43 +0700

SPECIFIC COMMENTS

Section 3
---------
Somewhere in the middle of the section (this section really _is_ too long!)
it says:
   o  One case is an inter-domain handover.  A trust relationship is
      required between the home and visited AAA domains.  Given that
      trust relationship and assuming the visited AAA domain supports
      ERP, full EAP authentication with the EAP server in the home AAA
      domain is still needed to distribute the existing keying materials
      to the ERP server when the mobile device first enters the visited
      AAA domain.
I'm not sure that a full EAP authentication is really necessary if
authenticated anticipatory keying (AAK) is in use.  IIRC, the reason for the
trip back to the HAAA wasn't required because full EAP authentication is so
much more secure than ERP (it might not be), but to let the HAAA know what
was going on and (as the draft says) to establish the appropriate keying
material in the (new) vested network.  Since one of the purposes of AAK is
to establish that material, the full EAP authentication might be extraneous.

Near the end of section 3, it says "It is assumed that there is at least one
candidate authenticator in each candidate access network while the serving
access network may or may not have a serving authenticator."  I'm not sure
that this ever made sense, but if we substitute "serving NAS" for "serving
authenticator" it certainly doesn't.  

In the next to last paragraph of the same section it says "When an
uthenticator acts as a pass-through authenticator, it communicates with the
EAP server typically implemented on a AAA server using a AAA transport
protocol such as RADIUS [RFC2865] and Diameter [RFC3588]."  The fact that an
authenticator typically communicates w/the EAP server via AAA is not
controversial, but the location of the EAP server is implementation-specific
and irrelevant.  Suggest changing to: "When an authenticator acts as a
pass-through authenticator, it typically communicates with the EAP server
using a AAA transport protocol such as RADIUS [RFC2865] or Diameter
[RFC3588]."

Section 3.1
-----------
The first sentence of the first paragraph says 
   The complexity of the authentication and authorization portion of
   handover depends on whether the handover involves a change of
   authenticator, and whether it involves a change in EAP Server.
I'm not sure how a handover could _not_ involve a change of authenticator.
Even if the handover took place within one NAS (say, between WiMAX &
802.11), it seems like there would separate EAP authenticators involved.

In general, I'm hard-pressed to see how inter-technology handovers are
different from any other _from the POV of EAP_; certainly, things are much
more complex in other ways, but not for EAP.  What am I missing?

Section 4.1.1
-------------
The first sentence says:
   In this model, the serving authenticator is not involved in the EAP
   exchange and only forwards the EAP pre-authentication traffic as it
   would any other data traffic, or there may be no serving
   authenticator at all in the serving access network.
If we replace "serving authenticator" with "serving NAS", the statement that
"there may be no serving authenticator at all in the serving access network"
makes no sense.  If what is really meant is that the serving NAS doesn't
participate in the preauthentication at all, then how is this different from
a normal EAP authentication in a "make before break" handover environment
(like CDMA)?

Section 4.1.2
-------------
The second sentence says:
   In this indirect pre-authentication model, it is assumed that a trust
   relationship exists between the serving network (or serving AAA
   domain) and candidate network (or candidate AAA domain). 
It's not clear to me how a trust between the respective AAA servers in the
serving & candidate networks is relevant or useful here, since the none of
the signaling between the two seems to be transiting those servers.  It
looks to me as if there must be a trust relationship between the two NASs &
between the candidate & home AAA servers for this to work.  Again, what am I
missing?

The second paragraph says:
   The role of the serving authenticator in this pre-authentication
   model is to forward EAP pre-authentication signaling between the peer
   and candidate authenticator and not to act as an authenticator for
   the candidate point of access.  It continues to act as an
   authenticator for the serving point of access.  
Unless the "serving authenticator" is using EAP to forward signaling in some
unknown fashion, it can't be doing that; in any case, I can't see how it is
relevant to the topic under discussion whether or not it "continues to act
as an authenticator for the serving point of access".

Section 4.2
-----------
Paragraph 3, second sentence says:
   This is not the simple mediation function of an authenticator,
   because the SA-AAA signaling in this case must identify the candidate
   authenticator to which keying material must be pushed.  
I don't really understand this statement.  Since the peer presumably knows
the identity of the candidate, couldn't include that it an EAP packet (maybe
in a NAI decoration)?  In any case, I'm not sure how or why the serving
whatever would know the identity of the candidate whatever in order to be
able to send it.

Section 6
---------
Under "Early authentication lifetime" it says "It is currently not possible
for a AAA server to indicate to the AAA client or a peer the lifetime of the
early authenticated session unless AAA protocols are extended to carry early
authentication session lifetime information."  Even if AAA protocols were to
be so extended, it wouldn't help the peer at all, since peers speak EAP; EAP
would need to be extended, as well.  Fortunately, AFAIK it's not generally
considered necessary for an MN to know how long its session will last. ;-)

Under "Early authentication retries" it says "However, if the peer has not
yet moved to the new location and realizes that the early authentication is
expiring, it may perform another early authentication"; WRT the peer
realizing that the earl authentication session is expiring, see my previous
comment.