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

From: Qiaobing Xie <[email-masked]>
Date: Wed, 05 Sep 2001 19:32:00 -0500

Erik,

See my comments below... (I am doing catch-up on my emails after the
long holidays)

-Qiaobing

Erik Guttman wrote:
> 
> 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.

I like your following approach of layered analysis. But your this
analysis is focused only on the PU-to-PE relationship.

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

Good point. This should be captured in the security consideration of the
protocols.

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

agreed.

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

Not necessarily. For instance, after receiving a PE list from the name
server, the ASAP layer of the PU can pre-set a separate TLS/SCTP or
TLS/TCP channel with each of the PEs in the pool. When redirection is
performed, the PU's ASAP layer could simply send the data to a different
PE through the pre-set TLS channel.

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

Again, if ASAP is managing all the IPsec SAs, I think this can be solved
by pre-setting SAs to all PEs.

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

The above conclusion may not be correct, i.e., the lower layer security
may not necessarily break.

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

Are you suggesting that we get into the business of defining L5 security
with RSERPOOL? This is very questionable and is not an Rserpool
objective in my mind. I don't think I agree with you here. 

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

'transport-based' security can still be used as I've explained above.

> 
> > 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.
> 
> > 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.
> 
> > 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
> 
> > 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.
> 
> > Effect: Denial of service attack.
> 
> This is an active attack, not a DOS attack.
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> 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.

The term "node" and "object" are not clearly defined here. I'd suggest
we use "endpoint" consistently. Can you give a more specific definition
on "proxy registration"? 

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

We should only worry about the confidentiality of RSERPOOL's own
messages, not that of the user data. I agree with you that user data
confidentiality should be supplied at higher levels.

> 
> > 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.)
> 
> Erik
> 
> _______________________________________________
> rserpool mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/rserpool

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

---

From: Erik Guttman <[email-masked]>
Date: Thu, 6 Sep 2001 13:54:39 +0200 (MET DST)

> analysis is focused only on the PU-to-PE relationship.

Sure.  What are the PE-PE issues?

> PE through the pre-set TLS channel.

There are different security properties when multiple TLS connections
are established than one.  One has to put a lot of trust in the rserpool
implementation to get it right.  Also - SSL is pretty indiscriminate:
everything which has proper certification is 'equal.'

> by pre-setting SAs to all PEs.

Agreed.  See my comment to Senthil's mail.  I actually think that 
mapping to IPsec is not any harder than deploying IPsec in general.  
:-)

> objective in my mind. I don't think I agree with you here. 

Like it or not, this must be done.  Not as a service to higher layers
perhaps ('come one, come all, solve all your problems with L5 security!').
Rather, L5 must be secured so that it can provide its own reliable message
delivery services *safely.*

> 'transport-based' security can still be used as I've explained above.

Only if the transport security is managed in application specific ways.
For example, all SASL based apps have very tight specific application
coupling.  The App/transport coupling would have to be redesigned in 
each case to be App/RSERPOOL coupling.  This is what I mean by
saying legacy applications could not be supported.

> confidentiality should be supplied at higher levels.

Protecting user data could be done at lower layers with L5 coordination,
too.  I agree this is not a problem to take on at L5 (since there're
already security frameworks from the IETF at L7, L6, L4, L3 and L2!)
 
Erik