Subject: [Rserpool] RE: Erik Guttman's comments on Rserpool threats for review and comment - Part II

From: "Stillman Maureen (NVO-NIC/Ithaca)" <[email-masked]>
Date: Thu, 6 Sep 2001 08:13:15 -0500

I sent this yesterday and somehow it didn't get posted.  Here it is
again.  Sorry if it is a repeat post.

-- maureen

-----Original Message-----
From: Stillman Maureen (NVO-NIC/Ithaca)
To: [email-masked]'
Sent: 9/5/01 2:51 PM
Subject: RE: Erik Guttman's comments on Rserpool threats for review and
comment - Part II

Erik,

Here are my comments on the rest of your message which is mainly about
the text of the threat document.  Thank you for your input.  My comments
are preceeded and followed by ***.

Maureen,

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

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. 

*** OK, but I still think we should keep them separate during the phase
of
discussing the threat document.  When we look at solutions, we might
want to combine them. ****
  
> 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. 

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. 

*** I'll get a reading from the security group on this at the next
telecon. If anyone on the list has an opinion, that is good too.  Please
share it.  ***

> 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 

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 

*** This ends in mid thought.  Can you send the rest of this (or at
least 
finish the sentence)? ***

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

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

*** OK, it sounds like this describes a second effect on the system.  In
both cases a stream of reg/degre messages are sent, but with two
potential outcomes.  I will change this to say:

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: Corrupting the name server database and/or disabling the
Rserpool
discovery and naming function.   ***

> Effect: Denial of service.

This is an active attack, not a DOS attack. 

*** OK, I changed it as above, but if enough messages are flooded the
name server will not be able to perform.  ***
  
> Requirement:  An ENRP server that receives a
registration/deregistration 
> should not create or update state information until it has
authenticated 
> the PE. 

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

*** Same as your comment above on generic text.  We will decide soon.
***

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

*** I think this will depend on which solution we settle on.  I agree
that
this is an issue and we need to evaluate this when determining the
solution space. If all potential solutions create a heavy load on the
system, then this is a problem.  It may fall into the category of "this
is a problem that we can't solve so someone else needs to solve it".
****

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

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. 

*** Your comment helped me to "debug" this section.  Also, I named two
different things 3.3 thereby confusing myself in the process.  I will 
now rename them 3.1 - 3.4.  I will keep authentication and authorization
separate. Here is the capsule summary:

3.1 reg/dereg sent from malicious node on behalf of non-existant PE
PE does not exist
authentication -- fails
authorization -- fails

3.2 reg/dereg sent from malicious node on behalf of PE which is not
authorized
PE does exist
authentication -- fails
authorization -- fails

3.3 reg/dereg sent from malicious node on behalf of authorized PE
PE does exist
authentication -- fails
authorization -- succeeds

3.4  reg/dereg sent from PE which is not authorized
PE does exist
authentication -- succeeds
authorization -- fails

So, my text on 3.4 needs to be modified as follows:

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.

... should be "A PE who is not authorized to join a pool...."

As a closing note, any of these messages could be flooded, so you can
send a few or you can send a lot. ****

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. 

*** I agree with your question and I don't know the answer.  This should
be debated on the mailing list and at the teleconference. ****

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

Cut/paste. 
  
> 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. 

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.  

*** Someone brought this up as a threat during our discussions.  We
might ultimately decide that like TCP, we don't want to do anything
about it.  We also might decide that it will be used for a very specific
set of Rserpool messages, for example.  I believe that this will be
decided in detail during the security solution phase.  Thus, the threats
don't have to be "new", only specific to what we decide is a risk that
we want to protect against.  If you read the SAAG directive (OK, it is
still an internet draft and could change) draft-ietf-saag-whyenc-00.txt,
it says
that the IETF wants to do a better job of security in any newly defined
protocol. What "doing a better job" means is left up to the WG so we get
to decide.  Another related point is that we could decide that
confidentiality is mandatory to implement but optional to use.  That
gives the flexibility to use confidentiality where and when it is
appropriate but avoids the "we will implement it later (but later never
happens)" attitude.  ****

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

*** Again, your comment is an exploration the solution space, not a
description of threats.  Yes, we might support it at higher levels to
satisfy the requirement for confidentiality.  We need to debate this
later. 
***

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

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

*** I agree with your additions/clarifications here and will include
them.  The last sentence belongs in the solution space and we will defer
it for now. ****

-- maureen

Mobile: (607)227-2933

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

---

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Sep 2001 15:42:44 +0200 (MET DST)

Maureen,

>   dynamically which imposes additional concerns for the 

overall security of the end-to-end application.  This document explores
the security implications of RSERPOOL, both due to its own functions
and due to its being interposed between applications and transport
interfaces.

> finish the sentence)? ***

Sorry I broke off.
 
> creating false state information in the ENRP servers.

Why ENRP?  Why not 'RSERPOOL name service'?   Or as I describe
it in the architecture doc 'Naming and Discovery Function'.
 
> satisfy the requirement for confidentiality.  We need to debate this

I disagree.  This is not about the solution space but rather the
properties of the architecture.  What are the requirements of the
RSERPOOL layer?  Does it have to guarantee integrity, privacy,
authenticity, etc. of messages it handles for higher layers or not?

Erik