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

["Alper Yegin" <alper.yegin at yegin.org>]

Glen,

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

I re-read the Introduction section. I believe it provides enough info even
if we were to remove the last sentence that references the hokey I-D. Let's
note a possible action to revise that last sentence in case the hokey I-D
gets changed or stays in flux by the time we are in IETF LC. 


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

Right.

Serving network
	The access network through which the host gains access to the
intranet/Internet.

Candidate network
	One of the access networks that is a potential target of host's
handover.


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

Document says:

	Pre-authorization:  An authorization for a PaC, made by a CPAA for
      the PaC at the time of pre-authentication.

Not sure where a "pre-provisioned" filter comes into play. Basically
pre-authorization is the state a PaC reaches when it completes a successful
pre-authentication. And post-authorization is the state a PaC reaches when
it attaches to one of the candidate networks with whom it has reached
pre-authorization state.


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

I'm also thinking that the pre-auth SA and post-auth SA terms are not
useful. There is only one SA, it is called PANA SA. And that SA stays the
same before and after attachment to the candidate network. 

I'm unclear about the Mobile IP relevance. 


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

Not necessarily. There may be multiple candidate networks at any time.


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

I had the same comment. Unicast restriction is not necessary.


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

Yes.


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

You are right. The serving network does not have to be PANA-enabled.


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

Agreed.

 
> The second paragraph of section 5 is self-contradictory.

That accounting related text is in fact outside the scope of this document
(I had commented on its removal earlier).


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

I think you are right. We are already assigning the bit setting there.

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

I agree with this text's removal. 

Thank you for the good comments.

Alper