Subject: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt

From: "Glen Zorn" <[email-masked]>
Date: Wed, 24 Jun 2009 19:28:04 +0700

Please review this
(http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-08.txt)
ASAP.  I think that enough has changed to warrant another short review
period; I _really_ hate multiple WGLCs, though, so let's call it a "Last
Look" & set the end for 13:00 GMT on Wednesday, 1 July.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Mon, 29 Jun 2009 20:00:57 -0400

Hi,

I have reviewed the new version. The draft significantly improved and
addressed almost all the issues I have raised in my previous review
(http://www.ietf.org/mail-archive/web/hokey/current/msg01590.html).
There are a few issues left that I'd like to discuss. See my general
comments and a short list of nits below.

For future revisions, I would like to ask the editors to describe how
they addressed previously raised issues or why they didn't address some.
Otherwise it's very difficult to keep track of the discussion and new
draft releases.

Best regards,
Katrin

<General comments>

*) In the draft, it seems that EAP server and AAA server are used
interchangeably at times (or all the time?). For instance, in Section 5
<quote> Consider first the case where the authenticators operate in
pass-through mode, so that the EAP server is a AAA server </quote>. This
is not the correct definition of "pass-through mode". In all Figures EAP
Server and AAA Server are treated as the same entities. I think this
needs some further explanation/discussion and should be included in
Section 2, where EAP server and AAA server are defined.

*) I still don't understand what intra-authenticator handovers are!
Please explain and give examples, i.e. when are CAP and SAP the same
entities (Section 5)?

*) I still don't think you should refer to a full EAP authentication as
"normal authentication" because it suggests that the other
authentications, including early ones, are not normal.  Please change
"normal authentication" throughout the document to "full (EAP)
authentication" and add the term to the definition section.

*) In definition section 2, it is assumed that <quote> an attachment
point must also support EAP authenticator functionality </quote>.
However, later in the same section it is distinguished between
"Candidate Attachment Point (CAP)" and "Candidate Authenticator". With
the first definition, such distinction seems redundant, no?

*) The direct pre-authentication model is the only one for which no
assumptions or conditions are listed. I suggest rewording the
description from Section 6.1.2 <quote> This pre-authentication model is
needed if the peer cannot discover the candidate authenticator's
identity or if direct IP communication between the MD and CAP is not
possible due to security or network topology issues. </quote> as
conditions for the direct pre-authentication model.

</General Comments>

<Old&new nits>

*) Section 3.2.1.1: remove round brackets in last sentence
*) Section 3.3.1: add a period after last sentence
*) Section 6.1.1: Figure 2 is not referenced
*) Section 6.1.2: add a period after the first sentence
*) ": remove the space before the period in the last sentence
*) Section 8: change "a early authentication" to "an early
authentication"
*) Section 8: "Early authentication entries", you say the procedure for
changing a peer's state from early to full authentication is not topic
of <quote> this particular subsection </quote>. Where in this document
is this procedure explained? Please reference.
*) Section 8: "Multiple candidate attachment points: add a period after
last sentence.
8) Section 9: change "a early authentication" to "an early
authentication"

</Old&new nits>

<
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Glen Zorn
> Sent: Wednesday, June 24, 2009 7:28 AM
> To: [email-masked]
> Subject: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt
> 
> Please review this
>
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 30 Jun 2009 11:22:09 +0700

Hoeper Katrin-QWKN37 [mailto:[email-masked]] writes:
> Hi,
> 
> I have reviewed the new version. 

Thank you!

> The draft significantly improved and

http://tools.ietf.org/rfcdiff seems to work pretty well; certainly, you know
what your own comments were & can see if they have been addressed, no?

> pass-through mode, so that the EAP server is a AAA server </quote>.

I thought that I had rooted out all that nonsense, but I apparently missed
that one.  

> This
> is not the correct definition of "pass-through mode". 

I interpret the text as exemplary, not defining.

> In all Figures
> EAP
> Server and AAA Server are treated as the same entities. 

Section 4 says "These functional elements include a mobile device, a SAP, a
CAP and an one or more AAA and EAP servers; for convenience' sake, the AAA
and EAP servers are represented as being co-located."  This is meant to
apply to all the figures in the draft, but apparently that's not clear.

> I think this

Actually, "AAA server" isn't defined; care to suggest a definition?
 
> Please explain and give examples, i.e. when are CAP and SAP the same

I don't see where section 5 says anything about the SAP and CAP being the
same entities, but it's not hard to imagine cases in which this would be
true: any attachment point implementing two different L2 technologies, for
example.  Recall that the 'A' in SAP & CAP doesn't stand for
'authenticator'.

> authentications, including early ones, are not normal.  

But they aren't normal (of course, they're not psychotic, either, just
exceptional ;-).

> Please change

No.  Possibly the major problem with the original draft was that it glommed
together a bunch of related functionality (AAA client, L2 crypto (including
key management) EAP authenticator, etc.) into a single entity called the
"authenticator" (in this following 802.11).  We have tried to get rid of
that in this version by clearly delineating the various functional entities
involved, as well as renaming what was formerly the "authenticator" to
"attachment point".  

> conditions for the direct pre-authentication model.

I don't see the need for total consistency, but if you have some text...

> *) Section 3.2.1.1: remove round brackets in last sentence

OK

> *) Section 3.3.1: add a period after last sentence

OK

> *) Section 6.1.1: Figure 2 is not referenced

So what?

> *) Section 6.1.2: add a period after the first sentence

OK

> *) ": remove the space before the period in the last sentence

OK

> *) Section 8: change "a early authentication" to "an early

OK

> is this procedure explained? 

I don't think that it is; is it even in the scope of this document?

> Please reference.

OK

> 8) Section 9: change "a early authentication" to "an early

OK

...

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 30 Jun 2009 10:31:23 -0400

Glen,

Thanks for your clarifications. See my comments in line.

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Monday, June 29, 2009 11:22 PM
> To: Hoeper Katrin-QWKN37
> Cc: [email-masked]; [email-masked]; 'Yoshihiro Ohba'; 'Glen Zorn'
> Subject: RE: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt
> 
> http://tools.ietf.org/rfcdiff seems to work pretty well; certainly,
you
> know

[KH] Yes, I can do that, but I was wondering if some of my previous
comments have not been addressed for a reason (and not just accidently).
So instead of bringing up the same issues over and over again, I'd
prefer discussing the remaining issues on the list. Like we are doing
right now in this email :)
> Section 4 says "These functional elements include a mobile device, a
SAP,
> a
[KH] OK
> Actually, "AAA server" isn't defined; care to suggest a definition?
[KH] I just want to make sure that the definition is consistent with the
rest of the document...so I think it's best if you define it ;) On the
other hand a note about the relationship with an AAA server in the EAP
server definition is sufficient.

> example.  Recall that the 'A' in SAP & CAP doesn't stand for
[KH] OK, I understand now.

> But they aren't normal (of course, they're not psychotic, either, just

[KH] I trust your judgment as native speaker :) 
> involved, as well as renaming what was formerly the "authenticator" to
[KH] OK.
> I don't see the need for total consistency, but if you have some
text...
[KH] I didn't suggest it for consistency sake but rather to help to
distinguish the three use cases. For instance, if I want to implement an
early authentication solution, conditions&requirements for each model
would help me to identify the right approach for my system. Text could
be like "The direct pre-authentication model is based on the assumption
that the MD can discover candidate authenticators and establish a direct
IP communication link with them."
> > *) Section 6.1.1: Figure 2 is not referenced
[KH] IMO if a figure or table is not referenced at all it should be
removed.  So just reference it!

> I don't think that it is; is it even in the scope of this document?

[KH] That's exactly what I was wondering too! I don't think it is
discussed at all. So just mention that it is out of scope of the
document.