Subject: [Pana] WG LC: Pre-authentication Support for PANA

From: Basavaraj Patil <[email-masked]>
Date: Thu, 08 Jan 2009 13:52:12 -0600

Hello,

This is a WG last call for I-D: Pre-authentication Support for PANA
<draft-ietf-pana-preauth-04>.

The last call will end on January 22nd, 09. Please send your comments
to the mailing list prior to the deadline.

-Chairs

_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 8 Jan 2009 15:17:05 -0800

This is interesting.  I was under the impression that the draft in question
was under active discussion on this list, but the issuance of last call
implies that the document is technically complete & non-controversial.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Basavaraj Patil
> Sent: Thursday, January 08, 2009 11:52 AM
> To: [email-masked]
> Subject: [Pana] WG LC: Pre-authentication Support for PANA
> 
> 
> 
> Hello,
>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 15 Jan 2009 11:38:20 +0200

Here are my comments.

- "The PCI message MUST be unicast."

Not sure why we have such a constraint. Does using a non-unicast address
break anything? If not, let's not be constraining the spec unnecessarily.
Not that I see any use for this right away, but I don't see a reason to
prohibit future possibilities unless we see a value in having such a
constraint.

- "Once the PaC and CPAA have agreed on performing pre-authentication
      using the 'S' (Start) and 'E' (prE-authentication) bits, the
      subsequent PANA messages exchanged between them MUST have the 'E'
      (prE-authentication) bit set."

Not forever, right? We shall state "... MUST have the 'E' bit set until CPAA
becomes SPAA of the PaC".

- I didn't understand the utility of "Pre-authorization SA" and
"Pre-authorization SA" distinction. There is only one PANA SA. It does not
change when the PaC attaches to the target network. 

-  In an access network where accounting is performed, accounting starts
   when the pre-authorization SA becomes the post-authorization SA by
   default.  Depending on the pre-authorization policy, accounting may
   start immediately after the pre-authorization SA is established.

This spec should not care when acct starts. 

-    Since the mechanism described in this document is designed to work
   across multiple access networks, each EP in the serving network
   SHOULD be configured to allow PANA messages to be forwarded between a
   PaC and a CPAA only if the PaC has a post-authorization SA with the
   SPAA in order to avoid an unauthorized PaC to initiate pre-
   authentication.

Not sure why we have to say anything like that. PANA pre-auth is just UDP.
Unless the serving network "intends to block" pre-auth, it would not be
preventing pre-auth. 

An EP should allow PANA messages from unauthorized only if they are destined
to SPAA.
So, it should not blindly allow PANA messages. They may not only allow
pre-authentication (not that harmful), but they may even piggyback some data
to punch a hole through EP. I guess this is what the spec intends to talk
about, but it was not that clear to me from reading it.

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

This does not even describe what the issue could be. I don't see a value in
having this paragraph here.

Editorial:

-  If the PaC is a
   mobile device and is capable of moving one access network to another
   while running its applications,

s/moving one/moving from one

- allow the PaC to sent or receive packets

s/sent/send

Thank you.

Alper

> Sent: Thursday, January 08, 2009 9:52 PM
> To: [email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 Jan 2009 12:02:25 -0800

Second try: is it the opinion of the WG Chairs that there is firm consensus
around this document?  If so, may I ask what this determination is based
upon, given the ongoing discussions on this list?

> Alper Yegin
> Sent: Thursday, January 15, 2009 1:38 AM
> To: 'Basavaraj Patil'; [email-masked]
> Subject: Re: [Pana] WG LC: Pre-authentication Support for PANA
> 
> Here are my comments.
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 15 Jan 2009 14:18:50 -0600

Hi Glen,

Firm consensus might be a stretch of terminology.
The chairs believe that this document is useful in the context of PANA.
This has been echoed by people in the room at previous IETF meetings. And
hence the current WG LC to progress the document.

-Raj

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 Jan 2009 12:28:34 -0800

> The chairs believe that this document is useful in the context of PANA.

That would certainly be a good rationale for the document's adoption as WH
item; however, my understanding is that LC normally signifies that the
document is complete (unless you are planning to follow the recently popular
method of issuing multiple "Last" Calls).

> >> Not forever, right? We shall state "... MUST have the 'E' bit set
> until
> >> CPAA
> >> "Pre-authorization SA" distinction. There is only one PANA SA. It
> does
> >> not
> >>    SHOULD be configured to allow PANA messages to be forwarded
> between
> >> a
> >> Not sure why we have to say anything like that. PANA pre-auth is
> just
> >> UDP.
> >> pre-authentication (not that harmful), but they may even piggyback
> some
> >> data
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >>> Basavaraj Patil

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 15 Jan 2009 14:34:52 -0600

> method of issuing multiple "Last" Calls).

Don't plan on issuing multiple last calls...
So AFAICT this document is viewed as being complete. Are there opinions that
would contradict that view? What specifically is considered as being
incomplete that would impede the LC process?

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 15 Jan 2009 14:32:57 -0800

Basavaraj Patil [mailto:[email-masked]] writes:

> would contradict that view? 

As I've mentioned several times, I believe that this draft is the subject of
ongoing discussion, that last pair of messages of which were posted just
before and _after_ you issued last call.  Perhaps you were unaware (although
you were copied directly on both messages) of the debate?  Do you consider
the discussion to be irrelevant?  It just seems rather irregular to me.

> What specifically is considered as being
> >> This has been echoed by people in the room at previous IETF
> meetings.
> >> And
> >>>> Not that I see any use for this right away, but I don't see a
> reason
> >> to
> >>>>       subsequent PANA messages exchanged between them MUST have
> the
> >> 'E'
> >>>> Unless the serving network "intends to block" pre-auth, it would
> not
> >> be
> >>>> preventing pre-auth.
> >>>>
> >>>> An EP should allow PANA messages from unauthorized only if they
> are
> >>>> destined
> >>>> to SPAA.
> >>>> to punch a hole through EP. I guess this is what the spec intends
> to
> >>>> talk
> >>>> -    The pre-authentication mechanism defined in this document
> does
> >> not
> >>>>    link-layer specific context [I-D.ietf-hokey-preauth-ps],
> because
> >> the

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 16 Jan 2009 13:22:11 +0200

Glen,

> the discussion to be irrelevant?  It just seems rather irregular to me.

We expect to handle that discussion as part of the WG LC. Unless you see a
show stopper for WG LC stemming from that discussion, I don't see any point
in delaying WG LC instead of handling discussions as part of the WG LC.

Anyways, WG LC is on, and input is welcome.  

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 16 Jan 2009 10:57:52 -0800

Alper Yegin [mailto:[email-masked]] writes:

> We expect to handle that discussion as part of the WG LC. 

Splendid idea, very efficient!  To improve efficiency even further may I
suggest in the future following in the footsteps of the radext WG & simply
issuing WGLC as soon as the -00 is posted?  That way _all_ discussion can be
handled during LC & the busy lives of the chairs won't be cluttered with
pesky tasks like determining consensus, etc.

> Unless you
> see a

What I see seems to be considered irrelevant, since the Chairs apparently
believe that the result of that discussion will be no change to the existing
draft (the foregone conclusion strongly implied by the statement that
multiple LCs aren't expected & your implicit assertion that no showstoppers
exist).

---

From: Ashutosh Dutta <[email-masked]>
Date: Thu, 22 Jan 2009 20:53:59 -0500

reviewers, here are some additional comments.
Thanks
Ashutosh

******************************************************************************
Introduction
The Protocol for carrying Authentication for Network Access (PANA) 
[RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA 
(PANA Authentication Agent) in the access network. If the PaC is a 
mobile device and is capable of moving one access network to another 
while running its applications, it is critical for the PaC to perform a 
handover seamlessly without degrading the performance of the 
applications during the handover period. When the handover requires the 
PaC to establish a PANA session with the PAA in the new access network, 
the signaling to establish the PANA session should be completed as fast 
as possible.

AD: What is *as fast as possible*, can we give some values or threshold 
based on some ITU parameters, probably.

Terminology:

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

AD: Do we need to define authorization somewhere, what it means and 
which components are involved in the process?

Pre-authentication Procedure:

When a CPAA initiates pre-authentication, it sends a PAR message with 
the 'S' (Start) and 'E' (prE-authentication) bits set. The PaC responds 
with a PANA-Auth-Answer (PAN) message with the 'S' (Start) and 'E' 
(prE-authentication) bits set only if it supports pre-authentication. 
Otherwise, it MUST silently discard the message.

AD: How does CPAA know the address of PaC to initiate the process?

When a CPAA with which the PaC has a pre-authorization SA becomes the 
SPAA due to, e.g., movement of the PaC, the PaC performs an IP address 
update procedure defined in Section 5.6 of [RFC5191]

AD: procedure *as* defined in Section 5.6 of [RFC5191]

The IP address update procedure with the CPAA will not change the 
pre-authorization SA to a post-authorization SA.

AD: Above sentence is not very clear. What is the IP address update 
procedure here?

Authorization and Accounting Considerations:

while both the pre-authorization and post-authorization policies may 
allow installing credentials to the EP,

AD: installing credentials in the EP

Security Considerations :

In order to avoid possible resource consumption attacks on the PaC 
caused by a blind attacker initiating pre- authentication for the PaC by 
changing source addresses, the PaC SHOULD limit the maximum number of 
CPAAs allowed to communicate.

AD: What do you mean by *blind* attacker?

Thanks
Ashutosh

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 Jan 2009 15:32:57 -0500

Thank you for the review.

> based on some ITU parameters, probably.

We can add a reference here to hokey-preauth-ps draft for the actual
values.

> AD: How does CPAA know the address of PaC to initiate the process?

It is described as out of scope:

"
   There may be several mechanisms for a PaC and a CPAA to discover each
   other.  However, such mechanisms are out of the scope of this
   document.
"

> AD: procedure *as* defined in Section 5.6 of [RFC5191]

OK.

> AD: Above sentence is not very clear. What is the IP address update  

It means the IP address updated procedure as described in Section 5.6
of [RFC5191], but additionally with 'E' bit set.

> AD: installing credentials in the EP

OK.

> AD: What do you mean by *blind* attacker?

It means an attacker that can generate forged PANA messages without
need to intercept PANA messages being exchanges between PaC and PAA.
However, we can simply replace "a blind attacker" with "an attacker"
without losing what needs to convey here.

Best Regards,
Yoshihiro Ohba