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

["Glen Zorn" <gwz at net-zen.net>]

Hoeper Katrin-QWKN37 [mailto:khoeper at motorola.com] writes:
> Hi,
> 
> I have reviewed the new version. 

Thank you!

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

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?

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

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
> needs some further explanation/discussion and should be included in
> Section 2, where EAP server and AAA server are defined.

Actually, "AAA server" isn't defined; care to suggest a definition?
 
> *) 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 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'.

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

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

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

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

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

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

> 
> 
> </General Comments>
> 
> <Old&new nits>
> 
> *) 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
> authentication"

OK

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

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

> Please reference.
> *) Section 8: "Multiple candidate attachment points: add a period after
> last sentence.

OK

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

OK

...