Subject: [Rserpool] Next version of Rserpool threats for review and comment

From: "Stillman Maureen (NVO-NIC/Ithaca)" <[email-masked]>
Date: Tue, 28 Aug 2001 14:50:35 -0500

This document format is based on an Mobile IP v6 document on security
threats (see reference below).  We discussed this document during our
first security subgroup teleconferece.  It will be discussed again on
9/7/2001 at the second teleconference.  Anyone wishing to join should
send me an e-mail.

Please note the following:

1) I have separated authentication from authorization.  We can combine
them if the group thinks that is the right thing, but for now they are
separate.

2) Senthil's comments on cut and paste attacks (see his e-mail of
8/21/2001 are handled by a combination of protection against replay
attacks, 3.7 and integrity mechanisms 3.9, in my opinion.  Therefore,
there is not a separate item for a "cut and paste" attack.

3) Senthil's comment:
3.x Malicious entity sends spurious peer messages to ENRP servers is
equivalent to 3.4 Malicious ENRP server joins a group, in my opinion.

4) I have another comment on Senthil's e-mail which I will send
tomorrow.

5) Although there is a requirement listed here for each threat, the
group has not yet decided which threats we will protect against.  We
also might decide that another WG will solve the problem.  What is
listed here is open for debate.

6) This document does not propose solutions to any security problems.

Send any comments on this to the list.  We will also talk about this at
the next security teleconference.

-- maureen

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 flooding

Threat: A malicious node or PE could send a stream of
registrations/deregistrations that are unauthorized to 
register/deregister - 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 the authorization of
the registering/de-registering entity is verified.

3.3  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  PE Registration/Deregistration spoofing

Threat:  A malicious node or PE who is not authorized to join a pool
could send registrations/deregistrations to ENRP servers 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 authorized
the requesting entity.

3.4 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.5 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.6 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.7 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 or
update.

Effect: False/extra state is maintained by ENRP servers

Requirement:  Care should be taken to prevent replay attacks.

3.8 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.9  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.

3.10 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.

3.11 ENRP Server Discovery

Threat: When a PE wishes to register with an ENRP server, it needs to
discover an ENRP server. An attacker could thwart the successful
discovery of ENRP server(s), thereby inducing 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 ASAP on
behalf of a PU needs to discover ENRP servers as well.

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

Requirement: Discovery phase needs to be authenticated.

4.0 References:

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

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

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

---

From: Erik Guttman <[email-masked]>
Date: Wed, 29 Aug 2001 10:38:42 +0200 (MET DST)

Maureen,

I have a few general notes.  I regret I don't have time to directly
participate in the security design team, but I hope my remarks will
be of use to that group.

I believe the most important class of security risks are not addressed
in this document.  I see RSERPOOL as a session layer protocol.

Consider how this interacts with existing security protocols.

   7 APP           <--------------> APP  
                    custom ciphered data

   6 PESENTATION   <--------------> PRESENTATION
                    S/MIME, PGP

   5 SESSION       <--------------> SESSION 
                    ?

   4 TRANSPORT     <--------------> TRANSPORT
                    TLS, SASL

   3 NETWORK       <--------------> NETWORK
                    IPSec

   2 LINK          <--------------> LINK
                    WEP, EAP

RSERPOOL will eliminate the correspondence between client and server.
That is, in the middle of a series of exchanged messages, the client
may actually correspond to a different server instance.

Implications, per layer:

7: Cipher state must be shared among PE instances, or else apps
   will no longer be able to communicate.  As long as state sharing
   exists, and the state isn't less secure due to its being shared,
   app layer security is not compromised.

6: Presentation layer security is not compromised.  Consider the
   keying material required for processing S/MIME encrypted messages
   is distributed between a set of PEs.

4: Transport layer security is compromised by session layer 
   redirection of transport between divergent parties.  Consider
   SASL based authentication used for IMAP, LDAP, etc.  A TCP
   connection is initially authenticated through an exchange of
   messages and constitutes a 'session.'  This would clearly be
   broken by RSERPOOL.  TLS would also be broken.  I don't believe
   this state can be shared and connections reestablished.  Doesn't
   SSL use IP identifiers in the protocol?

3: IPsec security associations between IP endpoints would clearly be 
   broken by redirection of traffic at the session layer.

etc.

The point is that security mechanisms and properties of higher layers 
can be supported transparently by a session layer which redirects or 
restarts communication (though this may have some state sharing 
assumptions which itself has security implications).  The security 
mechanism and properties of lower layers will be broken by a session
layer which effectively reroutes communication arbitrarily across them.
This does not imply that lower layer security is inappropriate or 
ineffective when used in conjunction with RSERPOOL, only that it has
completely different implications.

If an application relies on IPSec for security, RSERPOOL will
break this.  

However, RSERPOOL itself could rely upon IPsec for *its* security.
The idea being that if the application can be made to rely upon layer 
5 for its security, layer 5 can in turn support that through lower
layer services.

Note that no existing application today uses L5 security, since it
doesn't yet exist in the Internet protocol suite - we are talking about
new applications.  The only legacy applications which could be supported
with existing security mechanisms and properties using RSERPOOL are those
which use 'object-based' security as opposed to 'transport-based'
security, that is, for example S/MIME, PGP secured messages.

> them if the group thinks that is the right thing, but for now they are

Separation of these two is important if there are different policies
which may be associated with an authenticated principal.  It really
depends whether RSERPOOL requirements view all PUs and PEs as being
equal or distinguish between their rights and permissions.  If there
is a single policy it is simpler to define, implement and deploy - and 
we can combine authentication & authorization.
 
> equivalent to 3.4 Malicious ENRP server joins a group, in my opinion.

Can we discuss security on for the naming resolution and discovery
function as opposed to ENRP?  I say this since it is possible RSERPOOL
will standardize on something other than ENRP to support these functions.

> is a threat analysis document for mobile IP v6.

Suggested text:

  RSERPOOL provides a session layer for robustness and performance.  The
  session layer function may redirect communication transparently to upper
  layers.  This alters the direct one-to-one association between 
  communicating endpoints which typically exists between clients and 
  services.   In particular, secure operation of protocols often relies
  on assumptions at different layers regarding the identity of the 
  communicating party and the continuity of the communication between 
  endpoints.  Further, the operation of RSERPOOL itself has security
  implications and risks.  The session layer is organized and operates
  dynamically which imposes additional concerns for the 

> servers at a very rapid rate and thereby create unnecessary state in an

A malicious node could send a stream of spurious reg/dereg messages 
in order to disable the RSERPOOL discovery and naming function.

> Effect: Denial of service attack.

This is an active attack, not a DOS attack.
 
> should not create or update state information until it has authenticated

The RSERPOOL discovery and naming function should not update state 
until it has authenticated the PE originating the reg/dereg message.

> the registering/de-registering entity is verified.
 
NOTE:  This does not reduce the risk of DOS - you still have to 
authenticate each message.  The shear amount of work created by
this could be as damaging as spurious data.

> should not create or update state information until it has authenticated

Again - let's not discuss requirements for ENRP, but rather naming
and discovery function.   3.3 is really a different case of 3.1 -
in both cases we have to determine whether the reg/dereg is authorized.

Question:  Are proxy registrations possible?  If so, it is not the PE
which is authorized or not, but rather the PE registration itself (not
endpoint security but object security).  This is a crucial distinction
to decide upon.

> should not create or update state information until it has authorized

Cut/paste.
 
> Requirement: Provision for Data confidentiality service.

The question is how does RSERPOOL establish new confidentiality risks
that other protocols lack?  If TCP is used in a client server protocol
the communication may also be snooped.  

If confidentiality is required, why not supply it at higher levels
(encrypt data at the application (PGP) or presentation layer (S/MIME))
or lower layers - IP layer (IPsec), link layer...)

> Requirement: Discovery phase needs to be authenticated.

There are several threats:

1) thwarting successful discovery

   This would make it impossible to successfully complete
   the discovery operation.  This is a DOS attack.

2) spoofing successful discovery
  
   This would make an unauthorized naming service function server
   appear to be an authorized one, such that PEs would use it.
   This malicious naming service would either misrepresent, ignore
   or otherwise hide or distort information about the PE to subvert
   RSERPOOL operation.

Note there are requirements for a PU to discover naming service
functions as well.  PUs need the naming service to look up PE
information.  1) and 2) above apply to PUs as  well.

The requirements arising from 1 and 2 are different.  The requirement
for eliminating the risk of DOS is more subtle.  For example, one way
to thwart successful discovery would be to flood discovery replies 
which could not be authenticated.  The sheer volume of authentication
computation would impair successful discovery.  There are techniques
above and beyond authentication which reduce this risk (ie. use of
cookies which are computationally lightweight transactional IDs to
prevent authentication based DOS attacks.)

Erik