Subject: Re: [Pana] I-D: draft-ietf-pana-preauth
From: Qin Wu <[email-masked]>
To: [email-masked]
Date: Wed, 04 Feb 2009 14:27:26 +0800
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>

Hi,Yoshihiro:
Happy new year. Sorry for my so late reply.:) Please see my followup comments!
Best regards!
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: <[email-masked]>
Hi Qin,

On Thu, Jan 08, 2009 at 05:27:11PM +0800, Qin Wu wrote:
(snip)

> [Qin] From the defintion of pana session in section 2 of RFC5191, the termination event usually happen in case of failure or authentication exception. I can not see any mechanism to keep session continuity.
>  I wonder whether PANA session need to support mobility? What's the relationship between PANA session and mobile IP session?

Mobility aspect is considered in Section 5.6 of RFC 5191,
[Qin] As regarding mobility consideration in section 5.6 of RFC5191, it is still ambiguious to me. Since PANA session is a IP session, I wonder in the scenario when PaC moves from the old IP link to the new IP link and before PAA can be notified about the change of PaC Address, how PANA session is maintained. 
What's more, when the PAA can be notified about the change of PaC address?  and there is no need for a home address that does not change in order to maintain
the IP address change for PANA session.  This is because PANA does not carry any application traffic unlike Mobile IP.
[Qin] I agree PANA session does not need a home address for a PaC. Do you think PANA session has nothing to do with mobile IP. PANA preauthentication protocol can be used without invovlement of moble IP? How to understand the PANA session can be maintained? 
If the PANA preauthentication protocol can be used with Mobile IP,  what's the order or sequence for the PANA session and Mobile IP session?
> > 
> > What I meant is, there are two pre-authentication sceanarios (i.e.,
> > direct pre-auth and indirect pre-auth) and PANA pre-auth is defined as
> > one solution for direct pre-auth.  The draft-ietf-hokey-preauth-ps I-D
> > does not mention which pre-authentication scenario is better.
> [Qin] Correct. Actually what i concern here is in the model(Peer-CA-AAA)model, more threats will be introduced for layer 3 authentication without association with the CA.

Can you elaborate on new threats you consider?
[Qin] If you assume L2 connection has already been established between the PaC and CA and L2 connection between the PaC and SA is still maintained,
I think no more threats should be considered. However If you consider the scenario when L2 connection between the PaC and CA has not been estalished during
the PaC moves from the old link to the new link, I am afraid some malicious PaC can easily impersonate the legal PaC to pass through pre-authentication. Even one legal PaC can initiate pre-authentication to several target PAAs without the real attachment to the target link. In this way, If the PaC only attach to one of target link, PANA session established with the other target PAAs will be discarded which cause resource consumption attacks.
> > 
> > Please see my first comment above how the PANA session is supposed to stay during handover.
> > For enabling L2 ciphering before the pre-authorization SA becomes
> > post-authorization SA, I am assuming use of pana-pemk
> > (http://tools.ietf.org/html/draft-ohba-pana-pemk-02).  If this
> > mechanism is not available, then the target access network would have
> > to either allow IP address acquisition before L2 ciphering is enabled
> > or provide no L2 ciphering.
> [Qin] As I replied for your first comments, I can not see.

Please see my response above for why home address is not needed to
maintain the PANA session across IP address changes.

[Qin] I agree with this point. But the other point is since PANA session is layer3 session, how to understand the PANA session is maintained?
What's the difference between maintenance of Mobile IP seesion and maintenance of PANA session?

> As regarding L2 ciphering enabling, What i understand here is not a L2 connection maintenance but  a key distribution. 
> What's more, in some scenarios, the PAC can not establish L2 connection with Candidate PAA before Pac moves to the candidate PAA.
> based on this, it seems only dual radio case can work for PANA pre-authentication, i.e., the Pac not only attach to the old link but also attach to the new link before the Pac moves to the new PAA.

There is no need to establish L2 connection in the candidate network
before the PaC moves to the candidate PAA.

[Qin] Without L2 connection with candidate network before the PaC moves to the candidate PAA, How L2 cipering can work? Without L2 cipering mechanism,
How PANA session is maintained? Can you elaborate more details?

> >> [Qin] I want to point out whether or not use IP address to distinguish the two SA, each SA should include IP address.
> >> Also I don't think use on bit of 'E' is more secure than use one IP address. 
> > 
> > I believe 'E' bit is more secure than IP address because 'E' bit is
> > protected once PANA SA is established while IP address is not protected.
> [Qin] What i undestand SA is setup in the Pac and PAA and Each SA will at least contain SPI, src IP address, dst IP address.
> what you understand 'E' bit will be encrypted during the 'E'bit  is carried in the PANA message, am i right?
> So I guess we talk about the different thing.

'E' bit is integrity protected, not encrypted.  We don't use the term
SPI for PANA.  Details on PANA SA is described in Section 5.3 of RFC
5191.

[Qin] So PANA SA is different from IPSec SA? Do you think PANA SA is bidirectional SA? SPI is not necessary in the PANA SA?

Thanks,
Yoshihiro Ohba
*******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*******************************************************************************************