Subject: [Pana] Re: review pana spec

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 30 Nov 2006 10:20:57 -0800 (PST)

Hi Yoshi,

the draft looks pretty good. I mainly went through the differences. Here are my comments. 

- Abstract calls it "link-layer" agnostic where as in the Introduction, there is
  "minimum" link-layer dependency. Having gone through this discussion many
  times it might be better to remove both these terms to avoid lengthy discussions :-)

-Why isn't Key-Id included in the PANA-AUTH-KEY ? If you have multiple MSKs, isn't there
  multiple PANA SAs and hence the Key-Id should be included ?

-Section 5.6 " Pac Updating its IP addresses" : Is this needed for basic operation of PANA ?
 The example given in the section makes me believe that it is not required. But it is required
 depending on what IP address you start with. Hence, some clarification is required.

-In the Security considerations, 
   11.8.  IP Address Spoofing

            There is no way to prove the ownership of the IP address presented by
            the PaC.  Hence an authorized PaC can launch a redirect attack by
            spoofing a victim's IP address.

  the first sentence is worded in such a way that there is no way to do it. But if SEND
  is deployed in access networks, then it should be possible. Sure, PANA by itself
  cannot do it.

-mohan

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Sunday, November 19, 2006 10:39 AM
> To: [email-masked]
> Subject: [Pana] Preliminary pana-pana draft (13a)
> 
> is available at:
> 
> http://www.panasec.org/docs/editing/pana-spec.html
> 
> (Now we get 17 pages reduction.)
> 
> Please do sanity check to make sure that all resolutions discussed in
> IETF67 and over mailing list are reflected appropriately.  Diff from
> revision 12 is also available.
> 
> As soon as sanity check is done, I will submit a new revision (13)
> which is to be used for IETF last call.
> 
> Regards,
> Yoshihiro Ohba
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Nov 2006 15:07:48 -0500

>   times it might be better to remove both these terms to avoid lengthy discussions :-)

For Abstract, we can replace "link-layer agnostic transport" with 
"network layer transport".  For Introduction we can remove 
"minimum link-layer dependency".

>   multiple PANA SAs and hence the Key-Id should be included ?

Thank you for pointing this out.  You are right, Key-Id needs to be 
included.  We can revise the text to:

"
  PANA_AUTH_KEY = prf+(MSK, PaC_nonce | PAA_nonce | Session_ID | Key_ID)

   where the prf+ function is defined in IKEv2 [RFC4306].  The pseudo-
   random function to be used for the prf+ function is specified in the
   Algorithm AVP in a PANA-Bind-Request message.  The length of
   PANA_AUTH_KEY depends on the integrity algorithm in use.  See
   Section 5.4 for the detailed usage of the PANA_AUTH_KEY.  PaC_nonce
   and PAA_nonce are values of the Nonce AVP carried in the first PANA-
   Auth-Answer and PANA-Auth-Request messages in the authentication and
   authorization phase or the re-authentication phase, respectively.
   Session_ID is the session identifier of the session.  Key_ID is the
   value of the Key-ID AVP.
"

>  depending on what IP address you start with. Hence, some clarification is required.

Perhaps what we need to say is that PaC needs to update its IP address
*used for PANA*.  (We don't need to say which IP address is used for
PANA, which may be described by deployment-specific PANA applicability
documents.)

Here is revised text for Section 5.6 (also reflecting Alper's
comment):

"
5.6.  PaC Updating its IP Address

   A PaC's IP address used for PANA can change in certain situations,
   e.g., when the PaC moves from one IP link to another within the
   same PAA's realm.  In order to maintain the PANA session, the PAA
   needs to be notified about the change of PaC address.  In order to
   maintain the PANA session, the PAA needs to be notified about the
   change of the IP address of the PaC.

   After the PaC has changed its IP address used for PANA, it MUST
   send a PANA-Update-Request message to the PAA.  The PAA MUST update
   the PANA session with the new PaC address carried in the Source
   Address field of the IP header and return a PANA-Update-Answer
   message.  If there is an established PANA SA, both
   PANA-Update-Request and PANA-Update-Answer messages MUST be
   protected with an AUTH AVP.
"

>   is deployed in access networks, then it should be possible. Sure, PANA by itself

You are right.  Also, an unauthorized PaC as well as authorized PaC
can launch the attack.  How about the following text?

"

   Without use of SEND (SEcure Neighbor Discovery [RFC 3971], there is
   no way to prove the ownership of the IP address presented by
   the PaC.  Hence an attacker can launch a redirect attack by
   spoofing a victim's IP address.  It is RECOMMENDED to use SEND to
   avoid such an attack.
"

Regards,
Yoshihiro Ohba