Subject: PANA security threats LC comments

From: Alper Yegin <[email-masked]>
Date: Mon, 05 May 2003 11:18:53 -0700

Here are Pete McCann's review comments on the PANA security threats I-D.
Thanks Pete!

Alper

-------------------8<-----------------------------

Comments on draft-ietf-pana-threats-eval-03.txt

In the abstract, (which is repeated in the introduction, which is itself bad
style):
  This document discusses the threats in general without referring to a
  specific authentication protocol.
Threats to what?  Should at least say "security threats to PANA
operation" or some such.

In Section 4.0:
  Note that the usage of word trust above does not mean trust
  relationship. It just denotes the belief about how the nodes involved
  in PANA behave in the future.
I'm not sure what these two sentences mean or why they are here in the
document.

Here and in later text, the term "non shared medium" is used when I
think you really mean a stronger concept: that of a non-shared medium
with good physical security.  Suggest you be explicit about this.

In Section 5.0:

Path 3 is said to be outside the scope, as it can be secured through
operator configured security association.  However, I think we need to
worry about more than just eavesdropping on this link.  One threat
might be from a poorly specified or underspecified interface on Path
3; e.g., if the EP relies on some form of encryption or message
integrity checks to guarantee against theft-of-service, then a
protocol is likely needed to distribute keys from PAA to EP.  I think
there is a real danger that such protocols may not exist for a
particular variety of EP or that an operator may disable or improperly
configure such functionality even if it is available.  This would lead
to unsafe operation.  This problem space is touched on briefly in the
final paragraph of section 5 and in Section 6.4, although the specific
threats I outlined are not mentioned.  I suggest explicitly adding
Path 3 to the scope of the document.

penultimate paragraph of section 5:
   As it is beyond 
   the scope of PANA to address these threats, this document does not
   discuss this further.
Should use a semicolon here, not a comma.

Section 6.0:
   "discusses about" should just be "discusses".

Section 6.1:
   "The agents like PAA " should be "The PAA".

  Suggest deleting:
   ", without which the network operator will not make any profit"

  Suggest re-wording:
   "Since in this  
   environment, nodes in the network cannot directly communicate with
   each other and may assume that the other end of the point-to-point
   link is the PAA, spoofing attacks are not present."
  To:
   "Spoofing attacks are not present because in this environment, the PaC
   may assume that the other end of the link is the PAA."

   "resembles" should be "resemble".

  Change "Since" to "Because" and drop following comma:
   "Since,  
   it is difficult to protect the discovery process,"

Section 6.2.1:
   "An attacker can send false authentication success or failure to the
   PaC."
  Should be:
   "An attacker can send false authentication success or failure message to
the  
   PaC."
  Be consistent in the rest of the section.

  Change "because" to "if" in the following sentence:
   "This attack is possible because the success or failure indication is
   not protected using a security association between PaC and PAA. "

Section 6.2.2:
  Remove comma from this sentence:
   "It is not possible
   to do such verification, if compound methods are used without being
   able to create cryptographic binding among them."

Section 6.3:
   "When the PaC leaves the network, it needs to inform the PAA before
   disconnecting from the network so that the resources used by PaC can
   be accounted properly."
  This statement seems to be making assumptions about the protocol which has
  yet to be specified (this is true of several other statements in the
document
  as well).  Also, I don't think it's always possible for a PaC to
anticipate
  disconnection.  Suggest re-wording this.

Section 6.4:
  Here is an example of some text that says "non-shared" when it
  really means "non-shared with good physical security."  Also, it is
  important that the physical security be interlocked with the upper layer
  identifiers; i.e., consider a booth at an Internet cafe that is usable by
  only one person at a time.  We need to make sure that the ingress filter
is
  changed whenever one person leaves and a new person enters.
   "These threats are absent in links that are not shared as simple
   ingress filtering can prevent one node from impersonating as another
   node."

Section 6.5:
  "AS" should be, "As" below:
   "AS it is hard to protect against, there is no specific requirement
   on DoS attack. Protocol should be designed carefully to mitigate or
   prevent such attacks."
  Does this mean you are giving up on protecting against DoS because
  it is too hard?  That doesn't seem reasonable.

Section 7.0:
  Make sure these are aligned with whatever changes you make above.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 5 May 2003 14:29:46 -0700

Pete,

Thanks for your review. Comments below.

> In the abstract, (which is repeated in the introduction, 

I thought repeat + addition is okay :-)

> Threats to what?  Should at least say "security threats to 
> PANA operation" or some such.
> 
Okay.

> I'm not sure what these two sentences mean or why they are 
> here in the document.

It is going to go.

> 
> Here and in later text, the term "non shared medium" is used 
> when I think you really mean a stronger concept: that of a 
> non-shared medium with good physical security.  Suggest you 
> be explicit about this.
> 
Okay. I will state it explicitly.

> In Section 5.0:
> 
> Path 3 is said to be outside the scope, as it can be secured 
> through operator configured security association.  However, I 
> think we need to worry about more than just eavesdropping on 
> this link.  One threat might be from a poorly specified or 
> underspecified interface on Path 3; e.g., if the EP relies on 
> some form of encryption or message integrity checks to 
> guarantee against theft-of-service, then a protocol is likely 
> needed to distribute keys from PAA to EP.  I think there is a 
> real danger that such protocols may not exist for a 
> particular variety of EP or that an operator may disable or 
> improperly configure such functionality even if it is 
> available.  This would lead to unsafe operation.  This 
> problem space is touched on briefly in the final paragraph of 
> section 5 and in Section 6.4, although the specific threats I 
> outlined are not mentioned.  I suggest explicitly adding Path 
> 3 to the scope of the document.
> 
We had some discussions recently on this. We are thinking of using
the midcom working group's results on this. I have still not
read their requirements. I do see your point. I will think about
this.

> Should use a semicolon here, not a comma.
Okay.

>    "An attacker can send false authentication success or 
> failure message to the  
>    PaC."
Okay.

>   yet to be specified (this is true of several other 
> statements in the document
>   as well).  Also, I don't think it's always possible for a 
> PaC to anticipate
Okay. 

>   only one person at a time.  We need to make sure that the 
> ingress filter is

I am not sure I understood this completely. When the person leaves,
if he unplugs the cable, the disconnect notification should clear
the filter out. Could you elaborate ?

>   it is too hard?  That doesn't seem reasonable.
How do you prevent the dos attack on CPU cycles where I keep bombarding
requests at PAA. The protocol itself cannot do much. On the other
hand, some form of cookie exchange is generally to prevent resource
exhaustion attack. So, I am not sure I understood you completely here.

>   Make sure these are aligned with whatever changes you make above.
Okay.

thanks
mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 6 May 2003 12:54:24 -0700

Pete,
 
> Can you guarantee that a disconnect notification will be sent?  Are
> you relying on carrier detect mechanisms in a wired network?  Can you
> guarantee that they can't be spoofed?
> 
> To be really secure, it seems like some administrator has to clear the
> filter when the person in the booth changes.  Or, the latch on the
> door should trigger clearing the filter.  This is essentially
> interlocking physical security with the ingress filter.
> 
Ok, i will clarify a bit more what non-shared means.

> I guess my confusion comes from the statement, "there is no specific
> requirement on DoS attack."  I agree that a cookie exchange mechanism

Ok, i will try to modify this or remove it.

> of some type will probably be necessary, and I hope that this
> statement doesn't rule it out.  I like the second sentence, "Protocol
> should be designed carefully to mitigate or prevent such attacks."
> 

thanks
mohan

> -Pete