Subject: [Rserpool] input for the security telecon tomorrow - Rserpool Threats

From: "Stillman Maureen (NVO-NIC/Ithaca)" <[email-masked]>
Date: Mon, 20 Aug 2001 13:03:56 -0500

I decided to document the threats that we have talked about so far as
input to the teleconferce tomorrow.  I think that all of the threats
listed here have been discussed at some previous time.  If you have
corrections/changes or additional threats please e-mail the list and/or
join us tomorrow.  

This format is being used by the Mobile IPv6 working group to figure out
their security requirements/solutions.  I used their format.  They
define the threat, then state the effect (there can be several) and then
state the security requirement.

-- maureen

Mobile: (607)227-2933

   Threats introduced by Rserpool and Requirements for Security
                             in response to Threats

i. Abstract

This note is an attempt to describe security threats against the
Rserpool protocol and the requirements for a security solution to thwart
these threats in environments where it is likely to be deployed. The
threats and requirements identified herein and the document should be
considered as work in progress.  This draft is modeled after [1] which
is a threat analysis document for mobile IP v6.

1.0 Introduction

2.0 Assumptions

3.0 Threats

3.1  PE Registration/Deregistration flooding

Threat:  A malicious node could send a stream of false
registrations/deregistrations on behalf of non-existent PEs to ENRP
servers at a very rapid rate and thereby create unnecessary state in an
ENRP server. 

Effect: Denial of service attack.

Requirement:  An ENRP server that receives a registration/deregistration
should not create or update state information until it has authenticated
the PE.

3.2 PE Registration/Deregistration spoofing

Threat:  A malicious node could send false registrations/deregistrations
to ENRP servers concerning a legitimate PE thereby creating false state
information in the ENRP servers. 

Effect: Misinformation in the ENRP server concerning a PE would get
propogated to other ENRP servers thereby corrupting the ENRP database.

Requirement:  An ENRP server that receives a registration/deregistration
should not create or update state information until it has authenticated
the PE.

3.3 Malicous ENRP server joins the group of legitimate ENRP servers

Threat: Malicous ENRP server joins the group of legitimate ENRP servers
with the intent of propogating inaccurate updates to corrupt the ENRP
database.

Effect: Inconsistent ENRP database state.

Requirement: Mutual authentication of ENRP servers.

3.4 Registration/deregistration with malicious ENRP server

Threat: A PE unknowingly registers/deregisters with malicious ENRP
server.

Effect: Registration might not be properly processed or ignored.

Requirement: PE needs to authenticate the ENRP server.

3.5 Malicious ENRP Name Resolution

Threat: The ASAP protocol receives a name resolution response from an
ENRP server, but the ENRP server is malicious and returns random IP
addresses or an inaccurate list in response to the pool handle.

Effect: PU application communicates with the wrong PE or is unable to
locate the PE since the response is incorrect in saying that a PE with
that name did not exist.

Requirement: ASAP needs to authenticate the ENRP server.

3.6 Re-establishing PU-PE security during failover

Threat: PU fails over from PE A to PE B.  In the case that the PU had a
trusted relationship with PE A, then the PU will likely not have the
same relationship established with PE B.

Effect: If there was a trust relationship involving security context
between PU and PE A, the equivalent trust relationship will not exist
between PU and PE B.  This will violate security policy.

Requirement: Either notify the application when fail over occurs so the
application can take appropriate action to establish a trusted
relationship with PE B OR reestablish the security context
transparently.

3.7  Integrity

Threats: 
a) ENRP response to name resolution is corrupted during transmision
b) ENRP peer messages are corrupted during transmission
c) PE sends update for values and that information is corrupted during
transmission

Effect: ASAP receives corrupt information for pool handle resolution
which the PU believes to be accurate.

Requirement: Integrity mechanism needed.

4.0 References:

[1] draft-team-mobileip-mipv6-sec-reqts-00.txt, July, 2001 -- Work in
progress.

_______________________________________________
rserpool mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/rserpool

---

From: "Sengodan Senthil (NRC/Boston)" <[email-masked]>
Date: Tue, 21 Aug 2001 08:31:50 -0500

Some additional input for the call.

- Senthil

> -----Original Message-----
> From: ext Stillman Maureen (NVO-NIC/Ithaca)
> [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 2:04 PM
> To: [email-masked]
> Subject: [Rserpool] input for the security telecon tomorrow - Rserpool
> Threats
> 
> 

Change the above to:

Threat: A malicious node could send a stream of false
registrations/deregistrations on behalf of PEs - that are either
non-existent or that it is unauthorized to register/deregister - to ENRP
servers at a very rapid rate and thereby create unnecessary state in an
ENRP server. 

Requirement:  An ENRP server that receives a registration/deregistration
should not create or update state information until the authorization of
the registering/de-registering entity is verified.

This handles the case of unauthorized entities aiming to
register/deregister valid PEs, and also the case the PE itself may be
non-existent.

> should not create or update state information until it has 

The requirement above may be modified as follows:

Requirement:  An ENRP server that receives a registration/deregistration
should not create or update state information until the authorization of
the registering/deregistering entity has been verified.

3.x Malicious node performs a replay attack

Threat: A malicious node could replay the entire message previously sent
by a legitimate entity. This could create false/unnecessary state in the
ENRP servers when the replay is for registration/de-registration/update.

Effect: False/extra state is maintained by ENRP servers

Requirement: While checking for authorization of the
registering/de-registering/updating entity, care should be taken to
prevent replay attacks.

3.x Malicious node performs a cut-and-paste attack

Threat: A malicious node could cut-and-paste relevant portions of a
previously sent legitimate message.

Effect: This could create false/unnecessary state in the ENRP servers
when the cut-and-paste results in a registration/de-registration/update.

Requirement: While checking for authorization of the
registering/de-registering/updating entity, care should be taken to
prevent cut-and-paste attacks.

> Requirement: PE needs to authenticate the ENRP server.

3.x Malicious entity sends spurious peer messages to ENRP servers in
pool

Threat: A malicious entity may send spurious messages to peers in the
ENRP server pool.

Effect: False information can be created within the ENRP servers, and
legitimate information may be modified.

Requirement: ENRP messages between peers needs to be authenticated.

> c) PE sends update for values and that information is corrupted during

d) PE's registration/de-registration with ENRP server is corrupted.
e) ENRP server's registration/de-registration with ENRP server pool is
corrupted.

> Requirement: Integrity mechanism needed.

3.x ENRP Server Discovery

Threat: When a PE wishes to register with an ENRP server, it needs to
discover a suitable ENRP server to register with. An attacker could
thwart the successful discovery of ENRP server(s), thereby reducing the
PE to believe that no ENRP server is available. For instance, the
attacker could reduce the returned set of ENRP servers to null or a
small set of inactive ENRP servers. A similar scenario also applies when
a ENRP server or PU needs to discover ENRP servers as well.

Effect: A PE that could have been in an application server pool is not
part of a pool. An ENRP server that could have been in an ENRP server
pool is not part of a pool. A PU is not able to utilize services of ENRP
servers.

Requirement: Discovery phase needs to be authenticated.

3.x PU contacts unauthorized PE

Threat: Upon name resolution, the ENRP server returns a list of PEs that
the PU is authorized to contact. A malicious PU contacts a PE other than
that authorized by the ENRP server.

Effect: This offsets the load-balancing of PEs, which can further result
in denial-of-service to certain other legitimate PUs.

Requirement: PU needs to be able to contact only an authorized PE.

3.x Data Confidentiality

Threat: An eavesdropper capable of snooping on fields within messages in
transit, may be able to garner information such as topology/location/IP
addresses etc. that may not be desirable to divulge.

Effect: Information that an administrator does not wish to divulge are
divulged.

Requirement: Provision for Data confidentiality service.

> [1] draft-team-mobileip-mipv6-sec-reqts-00.txt, July, 2001 -- Work in

[2] http://www.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt,
July 2001, work in progress.