Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt: Comments Reply

From: "Hasnaa Moustafa" <[email-masked]>
Date: Thu, 16 Nov 2006 11:22:21 +0100

Hi Pavan,
Thanks for these interesting comments.
The reply is below, inserted in your message. Hope all is clear now.

Thanks again.

Regards,
Hassnaa Moustafa

-----------------------------------
Message: 6
Date: Tue, 14 Nov 2006 14:43:42 +0530
From: "pavan_kurapati" <[email-masked]>
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt
To: <[email-masked]>
Message-ID:
       <[email-masked]
.infosys.com<[email-masked]>
Content-Type: text/plain;       charset="iso-8859-1"

Hi,
I have following comments on this draft.

1. Introduction: "Prevention again Impersonation". Change it to  'against'

Reply: Yes, it is typos

Reply /end

2. Section 4 : The last bullet points of the 2 sections point to same thing.
i.e changing QoS settings for gaining profit. What is the difference?

Reply: The difference is that the QoS bullet concerning the point of attacks
against an individual entity: means that an attacker may change the QoS
parameters of its own subscription to gain more advantage illegitimately.

However, the QoS bullet concerning the point of attacks against the access
network or a portion of it: means that an attacker can replay old packets
concerning the QoS parameters of another privileged client to configure
these QoS parameters for itself (thus we can say that the attacker in this
case is stealing the QoS parameters from privileged client though replaying
the corresponding packets, and the attacker is an illegitimate client of
coarse).  ABut, this bullet does not belong to the attacks against the
access network, so it should be displaced or merged with the above bullet.

This section can be re-written for clarifying our thoughts and for
readability means. Maybe the second part should be merged with the first
part because attacks to the network eventually result in attacks to
customers.

Reply /end

3. Section 5 seems to have lot of repeated information. For eg.,
5.6Man-in-the-Middle is discussed in previous sections as well (like
DoS attack
section). Also, 5.7 Network snooping is very similar to traffic analysis
section. Both can be merged.

Reply: Man-in-the-middle attacks can cause DoS, but it can be other thing
that DoS as message modification for example which impacts integrity. Also,
Traffic analysis is an example of attacks that can take place due to network
snooping. Network snooping may be in form of eavesdropping or monitoring
activities. But this section can be more organized so not to confuse the
readers. The section could be split into two parts: what attacks do exist,
and how can these attacks be done.

Reply /end

4.  6.1 one of the attacks mentions "man-in-the-middle attack causing access
loop configuration data retrieval from the policy server by an illegitimate
NAS". I see this as a security consideration between policy server and NAS.
In the begininning of this section it was mentioned that this is out of
scope and is not discussed. Just a minor comment on consistency.

Reply: Actually, for this section (this use case) there is no data retrieval
from the policy server by the NAS. Thus, this should be changed to
(man-in-the-middle attack causing access loop configuration data retrieval
by an illegitimate NAS). An adversary taking control over the NAS acts as a
Man-in-the-middle and can illegitimately receive the Access Loop Attributes
in place of the NAS.

However, in the Section 6.2 (Access Loop Configuration Use Case), this type
of attacks which are related to the policy server is possible, as the NAS
query the policy server to retrieve Access Loop configuration data (as
mentioned in the framework draft). So eavesdropping may take place on the
configuration data retrieved by off-path adversaries on the Internet (fifth
bullet in Section 6.2) and also an off-path adversary on the Internet can
damage subscribers related data in the policy server through for instance
making subscribers record inaccessible (sixth bullet in Section 6.2).

Consistency is not hurt, as we do not talk about the authentication and
authorization between the NAS and the AAA/Policy server (which is out of
scope of our work). But we are mentioning attacks that are related to the
ANCP operation and are concerning the communication between the NAS and the
AAA/Policy server. When the policy server is in direct contact with the NAS,
the ANCP attributes are translated by the NAS into Radius/Diameter
attributes.  What is in fact out-of-scope is how the user gets authenticated
and how the AAA server gets the authorization data. Once the AAA has the
authorization data, then it is given to the NAS, which is more in our scope.
The draft should discuss more on this point to avoid any ambiguity.

Reply /end

5. 6.2 Access loop Configuration :
first bullet point says that an onpath adversary on AN can change the access
loop configuration. I would not see it as a ANCP threat. If there is an
onpath adversay 'on' AN, the AN itself is compromised. So he would not wait
for ANCP to change the access loop configuration isn't it?

Reply: You are right, once on the AN, someone can listen to the ANCP
configuration parameters, and then change them.  The adversary does not need
to wait for the ANCP messages, but still such an adversary (attacker) might
look to the configuration to see the configuration that someone else gets (
e.g., one ISP might be interested what the customers of another ISP gets and
therefore might break into the AN to see this). In such case, the attack is
not a downgrading attack, but it is rather learning the attributes.  So this
bullet will be re-worked.

Reply/end

6. I am not sure how a DSL user can be 'on path' adversary. I assume 'on
path' adversary as someone residing between NAS and AN (As defined in
section 3). Bullet 4 of section 6.2 says that an on path adversary  can
configure his "own" profile with some other privileged client's profile. I
think it is possible only by someone  sitting between AN and NAS . He does
not have a user profile of his own. More explanation is required as to how
it can be possible?

Reply: It is not so sure that the DSL user should be only off-path. If I am
on a certain DSL line  that does not mean that I launch my attack directly
from my home, but rather I will do this via first trying to get into another
box (e.g., Ethernet switch between AN and NAS), which is an on-path attack
and not an off-path. Actually, this is a very important security threat, as
such attack does not result in any customer complaint or alarm, and the ISP
will not detect it.

Reply/end

7. 6.4 also talks about modifying parameters to adversary benefit. I do not
think an onpath adversary can do something for his own benefit. I see a DSL
user as an off path adversary who can do certain limited things
w.r.toloopback tests etc. How can he change profiles of his own or
someone else
using ANCP?

Reply: The same as above.
Reply/end

Regards,
Hassnaa Moustafa

Pavan Kumar Kurapati
Infosys Technologies Ltd,
Bangalore
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp