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

["Hoeper Katrin-QWKN37" <khoeper at motorola.com>]

Glen,

Thanks for your clarifications. See my comments in line.

> -----Original Message-----
> From: Glen Zorn [mailto:gwz at net-zen.net]
> Sent: Monday, June 29, 2009 11:22 PM
> To: Hoeper Katrin-QWKN37
> Cc: hokey at ietf.org; sunseawq at huawei.com; 'Yoshihiro Ohba'; 'Glen Zorn'
> Subject: RE: [HOKEY] draft-ietf-hokey-preauth-ps-08.txt
> 
> 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?

[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 :)
> 
> >
> > 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.
> 
[KH] OK
> > 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?
> 
[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.


> > *) 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'.
> 
[KH] OK, I understand now.

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

[KH] I trust your judgment as native speaker :) 
> 
> > 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".
> 
[KH] OK.
> >
> > *) 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...
> 
[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."
> >
> >
> > </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?
> 
[KH] IMO if a figure or table is not referenced at all it should be
removed.  So just reference it!

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

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