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

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

Qin,

> >> Hi,Yoshi and all:
> >> I have just realized the PANA pre-auth has got though last call.
> Sorry
> >> for my delayed comments. Let's summarize what we discuss on pre-
> >> authentication support for PANA as WG LC feedback.
> >> Firstly we have agreed that additional texts are needed to point out
> >> EAP authentication is performed over the PAR-PAN exchange as
> regarding
> >> figure 1 in section 3.
> >
> > Can you please summarize what exactly is needed and why. [I was
> hoping you'd
> > provide a brief recap for the sake of registering the discussion in
> WG LC
> > scope, hence this request...]
> [Qin] What I am asking here is whether one EAP method is indicated in
> the figure1 in section3, for there are four message exchanges before
> Pre-authorization,
> after that there are two message exchanges to establish keying
> materials.
> Yoshi replied to me:
> >>Sure, we can add some text that EAP authentication is performed over
> >>the PAR-PAN exchanges.
> As regarding what text should be added here, I look forward to seeing
> the updated version from Editor. Thanks.

OK.


> >> Also we have agreed to add some text to clarify in what situation to
> >> change the pre-authentication SA to a post-authorization SA in
> section
> >> 3? Actually what I still don't understand is how to avoid the remote
> >> node to update the pre-authentication SA to post-authorization SA
> with
> >> 'E'bit seeting? For the remote node also can carry 'E'bit during the
> >> message exchange with PAA.
> >
> > Not sure I understand this. I find this "pre-auth" vs. "post-auth" SA
> > confusing. There is one PANA SA. The PaC is either attached to the
> serving
> > network, or not. The two attributes are orthogonal to each other.
> Probably
> > there is no need to qualify the SA according to where the PaC is
> attached.
> [Qin] It is a little tricky to avoid distinguishing "pre-auth" and
> "post-auth" SA. But what I worry here is how to
> prevent the PaC playing the remote malicious node, e.g., the PaC sends
> PANA pre-authentication message without 'E'bit setting before the PaC
> moves to the Candidate PAA? Does it mean the Pac can establish post-
> auth SA?

I'd expect the access network to know the ingress of PANA messages. For
example, a PAA shall not allow PANA messages with "E" bit set if they are
coming from immediate access links, and not allow PANA messages that do not
have "E" bit set if they are coming from other than immediate access links.
The latter may even be enforced on the firewalls.

> >> Aside from these two points mentioned above, what I am difficult to
> >> understand are:
> >> 1.Since PANA session and Mobile IP session are both L3 session, I
> >> wonder
> >> whether maintaining PANA session is neccessary to be considered in
> PANA
> >> pre-authentication? Because Mobile IP has its mechanism to maintain
> >> session continuity? But PANA session doesn't.Until now,I have not
> seen
> >> any text in PANA basic protocol or PANA pre-authentication
> draft.Only
> >> some SA update mechanism can not keep the session ongoing.
> >
> >
> > I didn't understand this point. Mobile IP and PANA are orthogonal to
> each
> > other. MIP may or may not be available/used by the host that
> implements PaC.
> > So, what exactly is the issue?
> [Qin] This is only a general issue. So your point is PANA does not
> require Mobile IP and has its
> own mobility mechanism to keep the session continuity or allow the PANA
> session stops and restart again?

PANA session is managed by the use of PANA messages. 
Nothing to do with Mobile IP.


> >> 2.As Yoshi said, PANA Pre-authentication has nothing to do with the
> >> network layer mobility support(e.g., mipv4,mipv6,pmip6)? That's
> >> great,So the PANA preauthentication is not scoping about mobility
> >> protocols and shall not require mobility protocols.
> >> I wonder in which kind of scenarios PANA pre-authentication
> mechanism
> >> can be used if we don't consider integration PANA pre-authentication
> >> with MIP protocol?
> >
> > Please see my answer above.
> >
> >
> >> 3.As Yoshi said,L2 ciphering can not be used before L2 connection is
> >> established,So do you mean before the PaC moves to the Candidate
> PAA,
> >> the PaC has already establish L2 connection with Candidate PAA?
> >
> > No. The spec does not (and definitely should not!) suggest anything
> like
> > that.
> > What is the issue here (that led to this misunderstanding)?
> [Qin] The story on this issue is when I discussed with Yoshi about how
> the PANA session is supposed to stay during handover?
> He said :
> > 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.
> From his understanding mentioned above, I wonder whether the PaC has
> already  estalish L2 connection with Candidate PAA before the Pac moves
> to the Candidate PAA? That's my concern.

The answer to your question is no.

I assume we are talking about L2 ciphering. If pre-auth is used in
conjunction with that, I expect the L2 to be keyed using the PANA SA as soon
as the host attaches to the target network.

Alper






> 
> > Thank you.
> >
> > Alper
> >
> >
> >
> > In this
> >> way, do you mean the PaC has already attached to the Candidate PAA
> >> during PANA pre-authentication procedure? I look forward to seeing
> your
> >> clarification.
> >> Thanks a lot!
> >> -Qin
> >> ----- Original Message -----
> >> From: "Yoshihiro Ohba" <yohba at tari.toshiba.com>
> >> To: "Qin Wu" <sunseawq at huawei.com>
> >> Cc: <pana at ietf.org>
> >> Sent: Wednesday, February 04, 2009 11:03 PM
> >> Subject: Re: [Pana] I-D: draft-ietf-pana-preauth
> >>
> >>
> >> > Hi Qin,
> >> >
> >> > Please see my comments below.
> >> >
> >> > On Wed, Feb 04, 2009 at 02:27:26PM +0800, Qin Wu wrote:
> >> >> Hi,Yoshihiro:
> >> >> Happy new year. Sorry for my so late reply.:) Please see my
> followup
> >> comments!
> >> >> Best regards!
> >> >> -Qin
> >> >> ----- Original Message -----
> >> >> From: "Yoshihiro Ohba" <yohba at tari.toshiba.com>
> >> >> To: <pana at ietf.org>
> >> >> 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.
> >> >
> >> > Let's avoid circular discussion.  You are asking the same question
> >> > which I already answered:
> >> > http://www.ietf.org/mail-archive/web/pana/current/msg03191.html
> >> >
> >> >> 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?
> >> >
> >> > PANA does not carry application traffic and PANA has its own
> mobility
> >> > management mechanism.  Therefore, PANA session has nothing to do
> with
> >> > Mobile IP.
> >> >
> >> >> 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.
> >> >
> >> > What do you mean by "impersonate the legal PaC to pass through
> >> > pre-authentication"?
> >> >
> >> > Why will PANA session established with other PAAs be discarded and
> >> why
> >> > does it causes 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 I explained, the difference is PANA does not carry application
> >> > traffic while Mobile IP does.
> >> >
> >> >>
> >> >> > 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?
> >> >
> >> > L2 ciphering cannot be used before L2 connection is established.
> >> > Establishment of L2 connection and allow PANA traffic to pass
> through
> >> > EP is an operational requirement of PANA.  Please see RFC 5193 for
> >> > 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?
> >> >
> >> > PANA SA is bidirectional.
> >> >
> >> > Thanks,
> >> > Yoshihiro Ohba
> >
> >