[Pana] WGLC comments on draft-ietf-pana-preauth-04

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

The Introduction says: "The extension to the PANA protocol is designed to
realize direct pre-authentication defined in [I-D.ietf-hokey-preauth-ps]."
It would be good to provide some additional/other rationale for the
development of the extension, since the contents of draft-ietf-hokey-preauth
are somewhat fluid; it is by no means certain that taxonomy of
preauthentication currently espoused in that note will be maintained as-is,
nor that the category of "direct preauthentication" will continue to exist.

In section 2, the terms "serving network" and "candidate network" are used
without being defined.

In the same section, it appears that "pre-authorization" is simply a
pre-provisioned filter applied to all traffic but that is not actually clear
from the document.

I don't understand what a "pre-authorization SA" is, exactly, maybe because
it is misleadingly named: it doesn't appear that the transition between a
"pre-authorization SA" & a "post-authorization SA" has anything to do with
the arrival of keying material (before which no PANA SA can exist, if I
understand RFC 5191 correctly) and dynamic authorization parameters at the
CPAA.  The transition actually appears to be triggered by successful IP
address update, but isn't this unnecessary in the case when Mobile IP is in
use or movement is within the same subnet?

Section 3 says "A PaC that supports pre-authentication may establish a PANA
session for each CPAA."  This implies that there may be multiple
simultaneous CPAAs in the same candidate network.  However, the same section
states that "When a PaC initiates pre-authentication, it sends a
PANA-Client-Initiation (PCI) message with the 'E' (prE-authentication) bit
set.  The PCI message MUST be unicast."  The restriction to unicast seems
somewhat inefficient.  In addition, RFC 5191 seems to say that a PANA
session is initiated with the "Authentication and authorization phase"
(although it's not really clear what the starting point for a session is
since this may consist of multiple message exchanges).  For the purposes of
this document, is the transmission of a PANA-Client-Initiation (PCI) message
with the 'E' bit set or a PAR message with the 'S' (Start) and 'E'
(prE-authentication) bits set considered to initiate the Authentication and
authorization phase?

The use of PANA-specific language in sections 3 & 6 prohibits the use of
PANA preauthentication if the "serving network" (whatever that is -- see
above) does not, itself PANA.  The restriction seems unnecessary; isn't the
only real requirement that the PaC & CPAA have IP connectivity?

Section 4 says "the 'E' (prE-authentication) bit of PANA messages are set in
order to indicate whether this PANA run is for establishing a
pre-authorization SA."  There are a couple of poor uses of English here; for
example, "whether" should probably be "that" & "are" should be "is".  

The second paragraph of section 5 is self-contradictory.

In section 7, "the Flags field of PANA Header" should be "the Flags field of
the PANA Header".  It doesn't really look like IANA is being asked to do
anything, though, so I'm not sure why this section is even here.

The third paragraph of section 8 says

   The pre-authentication mechanism defined in this document does not
   have an issue on context binding in which link-layer independent
   context carried over pre-authentication signaling is bound to the
   link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
   same EAP transport protocol (i.e., PANA) is used for normal
   authentication and pre-authentication in the candidate network.

The first part of this statement makes no sense to me, while the second part
("because the same EAP transport protocol (i.e., PANA) is used for normal
authentication and pre-authentication in the candidate network") seem to be,
once again, overly restrictive.  Why couldn't PANA be used only for
preauthentication?

~gwz

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