Subject: Re: [Pana] I-D: draft-ietf-pana-preauth

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 6 Jan 2009 15:25:46 -0500

Hi Qin,

Sorry for my delayed response.  Please see my comments below.

On Tue, Dec 23, 2008 at 11:22:46AM +0800, Qin Wu wrote:
> Dear Yoshihiro:
> Thank for your reply, please see my followup comments below.
> -Qin
> ----- Original Message ----- 
> From: "Yoshihiro Ohba" <[email-masked]>
> To: "wuqin" <[email-masked]>
> Cc: "Basavaraj Patil" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, December 23, 2008 4:39 AM
> Subject: Re: [Pana] I-D: draft-ietf-pana-preauth
> 
> 
> > Hi Qin,
> > 
> > Thank you very much for the review!  Please see my comments below.
> > 
> > On Sun, Dec 21, 2008 at 02:50:41PM +0800, wuqin wrote:
> >> 
> >> 1.  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.
> >> 
> >>    [Qin]:Before the mobile device moves, is it true to establish a PANA session with the PAA in the new access network?
> > 
> > Yes.
> > 
> >>    How to keep this PANA session uninterruption during the mobile device moves? Which identifier is used to distinguish
> >>    this PANA session? the old IP address allocated in the old access network? the new IP address allocated in the new access     network? 
> > 
> > The PANA session is identified by the Session Identifier defined in
> > RFC 5141.  In the case of PANA pre-authentication, the old IP address
> > allocated in the old access network is used for establishing the PANA
> > session with the PAA in another access network.
> [Qin] The Mobile IP protocol allows the mobile move from one link to another link without changing its "home address". In this way, the transport and high-layer connection can be maintained. In PANA pre-authentication scenario, When the mobile attachs to the new link, the old IP address (i.e., old Care of address) will not be available, Before the mobile gets a new IP address, How can you keep the PANA session uninterruption? 

I am not sure what 'interruption' means here, but the PANA session is
supposed to exist until one of session termination events occur, and
handover is not listed as a session termination event.  Please see the
definition of PANA Session in Section 2 of RFC 5191 for the session
termination events.

> >>    
> >>    This document defines an extension to the PANA protocol [RFC5191]
> >>    used for proactively executing EAP authentication and establishing a
> >>    PANA SA (Security Association) between a PaC in an access network and
> >> 
> >>    [Qin]:It mentions after Pre-authentication, PANA SA is required to be established, However
> >>    withouth key materials derivation and delivery, a PANA SA can not be established. So key materials
> >>    derivation and delivery mechanism is one integral part of PANA Pre-authentication, is it true?
> >>    How to perform key materials derivation and delivery during the pre-authentication?
> > 
> > Key derivation and delivery for the candidate PAA is performed in the
> > same as normal PANA session, i.e., an MSK is derived and delivered to
> > the PAA from EAP server.
> [Qin] Since the key derivation and delivery happen before PANA SA establishment and after the successful pre-authentication, the key derivation and delivery is a integral part of pre-authentication.

Yes, and we assume the same key derivation and delivery mechanism as
for the normal EAP authentication is used for pre-authentication.

> >> 
> >>    a PAA in another access network to which the PaC may move.  The
> >>    proposed method operates across multiple AAA domains. 
> >> 
> >>    [Qin]:What I understand PANA authentication here is one kind of user authentication,  However without network entry,i.e.,     the PaC attaching to the new access network, why the new access network allow a PaC in the previous access network            establish a PANA SA with a PAA in the new access network? I wonder for network security consideration, whether a PaC far    away from the new Access network can get permission to be remote authentication?
> > 
> > Well, it depends on network access policies which is out of scope of
> > this draft.  If a PaC is communicating with the candidate PAA from an
> > access network that is not allowed for pre-authentication based on the
> > policies, then pre-authentication attempt can be rejected.
> [Qin] So you agree in some scenario, pana-preauthentication does not work. Actually if my understanding is correct, the existing access network owned by the operator does not support this feature,does it?

I guess I miss your point here.  I think nothing is wrong if the
existing access network owned by the operator does not support
pre-authentication.

> >> 
> >>    The extension to the PANA protocol is designed to realize direct pre-authentication
> >>    defined in [I-D.ietf-hokey-preauth-ps].
> >> 
> >>    [Qin]Why PANA protocol is only used to realize direct pre-authentication? Why indirect pre-authentication 
> >>    can not be realized based PANA protocol?
> > 
> > I think technicaly it is possible to use PANA for indirect
> > pre-authentication (described in draft-ietf-hokey-preauth-ps) as well.
> > However, in indirect pre-autentication, the role of the serving
> > authenticator is just forwarding EAP messages between peer and
> > candidate authenticator, and hence no EAP peer or authenticator state
> > needs to be maintained on the serving authenticator with regard to
> > pre-authentication.  So I would think that it may be too much for the
> > serving authenticator to use PANA for indirect pre-authentication.
> [Qin] I can not agree. In the draft-ietf-hokey-preauth-ps-05, it said Indirect pre-
>    authentication is needed if the peer cannot discover the candidate
>    authenticator's IP address or if IP communication is not available
>    due to security or network topology reasons.
>    It seems what you explain is not consistent with the text mentioned above.
>    Actually, if the serving authenticator can  perform pre-authentication on behalf of the mobile, it will alleviate the overhead of the mobile    greatly.

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.

> >> 
> >>    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] in order
> >>    to update the SPAA with the PaC's new address obtained from the new
> >>    serving network.  PANA-Notification-Request (PNR) and PANA-
> >>    Notification-Answer (PNA) messages with 'P' (Ping) bit set are used
> >>    for this purpose.  The completion of the IP address update procedure
> >>    will change the pre-authorization SA to a post-authorization SA.  In
> >>    this case, the 'E' MUST NOT be set in the PNR and PNA messages and
> >>    subsequent PANA messages.
> >> 
> >>    [Qin]It seems the IP address udpate procedure is a part of pre-authentication,
> >>    without IP address udpate, Pre-authentication can not be regarded as completion.
> >>    However before the IP address is updated, how to make PANA pre-authentication 
> >>    keep service continuity?
> > 
> > According to RFC 5193, the PaC dynamically or statically configures an
> > IP address prior to running PANA.  So we assume that the new IP
> > address is configured prior to completion of post-authorization with
> > CPAA.  This is certainly possible if lower-layer security for the
> > target access network is bootstrapped using the MSK established by
> > PANA pre-authentication before obtaining the new IP address.
> [Qin] I am confused here. 
> First, Why the target access network needs to be bootstrapped? I only heard about Bootstapping for the Mobile terminal.

I meant bootstrapping the mobile terminal for the target access network.

> Second, Since the pre-authoration SA is identified with the old IP address, When the Mobile moves the the target access network and has not obtained the new IP address, the old IP address will not be available, it means the pre-authorization SA is invalid. the PANA session will be interrupted for a while during the handover. In this situation, the PANA pre-authentication should depend on the layer 2 security before the pre-authorization  SA becomes the post-authorization SA. When and How is the layer 2 security established? 
> Before the mobile moves to the target network, whether the layer 2 connection should be maintained?

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.

> >> 
> >>    If there is another CPAA with which the PaC has a pre-authorization
> >>    SA and the PaC wants to keep the pre-authorization SA after the
> >>    change of SPAA, the PaC also performs an IP address update procedure
> >>    [Qin] Do you mean PANA pre-authentication can work for dual radio case or something else?
> > 
> > PANA pre-authentication can work with single and dual radios (but
> > effectiveness for dual radio case may not be so large).
> [Qin] I have to point out one thing here,
> Dual radios case means the mobile attachs to the old link and the new link simutaneously. Since the PANA pre-authentication support dual radio case, it means not only L3 connection (PANA session) but also L2 connection exist between the peer and the candidate authentication before the mobile moves to the target network, do they?

Yes.

> >>    
> >>    defined in Section 5.6 of [RFC5191] in order to update the CPAA with
> >>    the PaC's new address.  PNR and PNA messages with 'P' (Ping) bit set
> >>    is used for this purpose.  In this case, the 'E' (prE-authentication)
> >>    bit MUST be set in the PNR and PNA messages and subsequent PANA
> >>    messages.  The IP address update procedure with the CPAA will not
> >>    change the pre-authorization SA to a post-authorization SA.
> >>    
> >>    [Qin] At the first time when the PaC establish SA with one CPAA, the IP address update procedure
> >>    with this CPAA can change the pre-authentication SA to a post-authroziation SA? However,At the second time when the Pac       establish SA with another CPAA, why the IP adress update procedure with this CPAA can not change the pre-authorization to     a post authorization SA?
> > 
> > It depends on 'E' bit settings.  If the IP address changes but with
> > 'E' bit set, 
> [Qin]It is a typo here? what you want to said here is "If the IP address changes but without 'E' bit set"

This not a typo.  If 'E' bit is set for an established PANA session
with a pre-authorization SA, then it means that the pre-authorization
SA is kept as it is without migrating to post-authorization SA.

> >then migration from pre-authentication SA to
> > post-authentication SA will not occur.  On the other hand, the CPAA
> > should allow migration from pre-authentication SA to
> > post-authentication SA only from an interface that serves for its
> > access network to avoid undesired upgrading to post-authentication SA
> > by a remote node.  We can add some text on it.
> [Qin] It will be better.

OK.

> My understanding is only when the candidate network is a target network, the pre-authorization SA can become post-ahorization SA.

Yes.

> Upon one of candidate network becomes the target network, the other candidate network can not be viewed as the target network. also the pre-authoriation SA can not be allowed to become post-authorizaiton SA, it that right?

That's right.

> 
> >> 
> >> 
> >>    The pre-authorization SA and the corresponding PANA session between
> >>    the PaC and a CPAA is deleted by entering the termination phase of
> >>    the PANA protocol.
> >> 
> >>    Example call flows for PaC-initiated pre-authentication and PAA-
> >>    initiated pre-authentication are shown in Figure 1 and Figure 2,
> >>    respectively.
> >>    [Qin]In the example call flows, which steps are used to generate keying materials?
> >>    which step is used to establish the SA? 
> >>    How many roundtrips exchange it takes to perform pre-authentication between PaC and CPAA? how long it takes to complete
> >>    a full pre-authentication? what's the handover performance improvement in constrast with EAP pre-authentication? 
> > 
> > Keying material is established with CPAA in the last PAR/PAN exchange
> > with 'C' bit set, in the same way as RFC 5191.  
> Message exchanges
> > between PaC and CPAA for pre-authentication are the same as RFC 5191,
> > the number of roundtrips depend on the EAP method, 
> [Qin] what i concern here is in Figure 1: PaC-initiated Pre-authentication Call Flow, there are four piece of message changes before Pre-authroziation, after that, there are two piece of message changes to establish keying materials, It seems you indicate one EAP method is used here. So I suggest to add some text to clarify it. Thanks.

Sure, we can add some text that EAP authentication is performed over
the PAR-PAN exchanges.

> in the same way as
> > RFC 5191.  The only difference is additional 'E' bit is used in PANA
> > pre-auth.
> >I don't understand the last question since PANA
> > pre-authentication is an EAP pre-authentication.
> [Qin] Yeah, the pana is just a protocol to carry EAP message. Thank for your correcting me. 
> >> 
> >> 5.  Authorization and Accounting Considerations
> >> 
> >>    A pre-authorization and a post-authorization for the PaC may have
> >>    different authorization policies.  For example, the pre-authorization
> >>    policy may not allow the PaC to sent or receive packets through an
> >>    Enforcement Point (EP) that is under control of the CPAA, while both
> >>    the pre-authorization and post-authorization policies may allow
> >>    installing credentials to the EP, where the credentials are used for
> >>    establishing a security association for per-packet cryptographic
> >>    filtering.
> >> 
> >>    In an access network where accounting is performed, accounting starts
> >>    when the pre-authorization SA becomes the post-authorization SA by
> >>    default.  
> >>    [Qin] What's the main difference between pre-authorization SA and post-authorization SA?
> >>    Only IP address that distinguish these two SA?
> > 
> > We distinguish the two SA based on the 'E' bit settings.  It may be
> > possible to use IP address solely to distinguish the two SAs, e.g.,
> > PANA message from IP address that do not belong to the realm of the
> > PAA could be associated with a pre-authorization SA.  However, I would
> > not recommend that scheme because it will be vulnerable to IP address
> > spoofing.  IMO, it's securer to use proteced indication based on 'E'
> > bit (note that 'E' bit is protected in the last PAR/PAN exchange).
> [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.

Regards,
Yoshihiro Ohba

> > Thanks,
> > Yoshihiro Ohba
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pana
> 
_______________________________________________
Pana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pana

---

From: Qin Wu <[email-masked]>
Date: Thu, 08 Jan 2009 17:27:11 +0800

Hi, Yoshihiro:
Thanks for your reply. Please see inline.
Best Regards!

Qin Wu
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; "Basavaraj Patil" <[email-masked]>
Sent: Wednesday, January 07, 2009 4:25 AM
Subject: Re: [Pana] I-D: draft-ietf-pana-preauth

> definition of PANA Session in Section 2 of RFC 5191 for the session
[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?

> for the normal EAP authentication is used for pre-authentication.
[Qin] Thanks for your clarification.
> existing access network owned by the operator does not support
[Qin] You are right. I just want to get your confirmation about whether the existing access network can support pre-authentication mechanism.
It is not important now.
> 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.
> I meant bootstrapping the mobile terminal for the target access network.
[Qin] okay, I see.
> or provide no L2 ciphering.
[Qin] As I replied for your first comments, I can not see.
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.

> Sure, we can add some text that EAP authentication is performed over
[Qin] Good.
> 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.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 9 Jan 2009 11:09:40 -0500

Hi Qin,

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

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

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

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

Thanks,
Yoshihiro Ohba