Subject: [Pana] issue85 (question)

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 14 May 2004 15:59:11 -0700

As a result of recent discussion, I am preparing for adding new
messages PANA-POPA-Update-Request and PANA-POPA-Update-Answer to let
the PAA know the POPA of the PaC.

I have one question: Are these messages need to be integrity
protected?

I think the answer is yes in general, to prevent the host route to a
legitimate PaC from being altered by an attacker.  On the other hand,
this means that an EAP method that can generate keys would be needed
even for networks (e.g., DSL) that are secured by lower-layers.

Since there is an address ownership issue with regard to POPA, which
cannot be solved by integrity protecting the POPA update messages and
needs a mechanism outside the PANA protocol, I am wondering if the
POPA update procedure really needs to be integrity protected.

Opinions?

Yoshihiro Ohba

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

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 May 2004 11:12:43 -0700

> the PAA know the POPA of the PaC.

Semantically what PAA should learn is an IP address of the PaC, right?
Not necessarily "POPA". If so, we might consider using a more generic
name, that doesn't refer to "POPA" in the name.

> even for networks (e.g., DSL) that are secured by lower-layers.

When there is a PANA SA, we must use it I think. If there is not, that's
OK too. This is aligned with the rest of the protocol design.

In physically secured networks, operator doesn't have to use a
key-generating EAP method, hence there might not be a PANA SA.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 May 2004 11:12:43 -0700

Alper

---

From: Rafael Marin Lopez <[email-masked]>
Date: Mon, 17 May 2004 20:58:51 +0200

>POPA update procedure really needs to be integrity protected.
In my opinion , PANA SA should be used when it exists . In another case,
when networks are not secured by low-layers, a man-in-the-middle could
modify this PANA-POPA-Update-Request. If PANA SA is used, I think PAA
could know attacker is same PaC which is sending
PANA-POPA-Update-Request. But if it is not used , PAA could not know if
attacker is an PaC sending POPA Update or a man-in-the-middle element.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Rafael Marin Lopez <[email-masked]>
Date: Mon, 17 May 2004 20:58:51 +0200

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 May 2004 12:46:29 -0700

> name, that doesn't refer to "POPA" in the name.

I used the term POPA because the issue starts from the issue of PRPA
to POPA update.  Do you have some other scenarios for the PAA needs to
learn an IP address of the PaC, or do we just use generic naming just
in case for other usages for this message exchange are found out?

> OK too. This is aligned with the rest of the protocol design.

Hmm, according to the following text in section 4.4, PANA-Reauth
exchange always needs a PANA SA to exist (I think the occurence table
marking the MAC AVP as "0-1" is typo.)  So I don't think the protocol
design is completely aligned that way.

   "Both PANA-Reauth-Request/ PANA-Reauth-Answer
   messages MUST be protected with a MAC AVP."

> key-generating EAP method, hence there might not be a PANA SA.

Or should we say "in physically secured networks, operator doesn't
have to use a key-generating EAP method except for PANA-Reauth
exchange"?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 May 2004 13:11:08 -0700

> > > messages PANA-POPA-Update-Request and PANA-POPA-Update-Answer to 
> > > let the PAA know the POPA of the PaC.
> >
> > Semantically what PAA should learn is an IP address of the PaC, 
> > right? Not necessarily "POPA". If so, we might consider using a more

> > generic name, that doesn't refer to "POPA" in the name.
> 

> in case for other usages for this message exchange are found out?

Yes, it is the latter that I'm thinking. The PAA needs to know any
reachable IP address of the PaC, so that it can send a (solicited or
otherwise) message. The IP address does not get any special treatment as
a "POPA".  

> > > I think the answer is yes in general, to prevent the host route to

> > > a legitimate PaC from being altered by an attacker.  On the other 
> > > hand, this means that an EAP method that can generate keys would 
> > > be needed even for networks (e.g., DSL) that are secured by 
> > > lower-layers.
> > >
> >
> > When there is a PANA SA, we must use it I think. If there is not, 
> > that's OK too. This is aligned with the rest of the protocol design.
> 

I think this is a bug. We don't want to limit the use of Reauth messages
to only when there is a PANA SA.

> have to use a key-generating EAP method except for PANA-Reauth 

I think we can have Reauth run without a MAC AVP. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 May 2004 12:46:29 -0700

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 May 2004 13:11:08 -0700

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 17 May 2004 14:31:36 -0700

> the PAA know the POPA of the PaC.
What happened to the device-id update ? I thought we wanted to use a generic
update mechanism that can use either device-id or POPA.

> POPA update procedure really needs to be integrity protected.
I agree with others that "use protection when there is PANA SA" approach.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 May 2004 15:48:43 -0700

> update mechanism that can use either device-id or POPA.

OK, how about PANA-Address-Update-{Request,Answer}?

> I agree with others that "use protection when there is PANA SA" approach.

OK.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 17 May 2004 14:31:36 -0700

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 May 2004 15:48:43 -0700

OK.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 06:53:10 -0700

> update mechanism that can use either device-id or POPA.

One more question: can't it be used for updating both device-id and
POPA at the same time when MAC address is used for the device-id?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 May 2004 06:53:10 -0700

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 18 May 2004 09:14:54 -0700

> POPA at the same time when MAC address is used for the device-id?
I guess so. So, calling it something like "PANA-update-{Request/Answer}"
and then carrying two separate AVPs like "device-id" and/or "Address" would
be generic enough to handle all the cases.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 18 May 2004 09:14:54 -0700

-mohan

---

From: Rafael Marin Lopez <[email-masked]>
Date: Tue, 18 May 2004 18:59:41 +0200

>be generic enough to handle all the cases.
Yes I like this idea... sounds good.

---

From: Rafael Marin Lopez <[email-masked]>
Date: Tue, 18 May 2004 18:59:41 +0200