Subject: [AAA-WG]: [issue] Security model for peer discovery and redirect

From: David Spence <[email-masked]>
Date: Wed, 06 Mar 2002 10:47:26 -0500

Subject: [issue] Security model for peer discovery and redirect

Submitter name: David Spence
Submitter email address: [email-masked]
Date first submitted: March 6, 2002
Reference: 
Document: Base
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

   While I haven't studied studied base-10 in great detail yet, I 
   believe there are still significant security issues with peer-to-peer 
   connections that need to be addressed.

   Two of the models for using Diameter that I'm not particularly
   thrilled with and admittedly haven't devoted a whole lot of thought
   to in the past are the peer discovery and redirect models.
   Nevertheless, it is extremely important that if we include these
   models in Diameter, we need to make them work.  The thing that both
   of these models share is that peer-to-peer connections are created
   dynamically.  This raises two problems.  The first is, what makes the
   connection originator feel comfy about seeking to establish the
   connection?  The second is, what makes the connection recipient feel
   comfy about accepting the connection?

   Consider the redirect model.  If [email-masked] dials in to
   wondernet.net, the wondernet AAA server, aaaf.wondernet.net, sends an
   authentication/ authorization request to his redirect agent,
   aaa.omniscient.com.  Aaa.omniscient.com redirects him to
   aaah.donut.com.  Aaaf.wondernet.net is comfy because he trusts
   aaa.omniscient.com.  Aaah.donut.com receives a CER from
   aaaf.wondernet.net.  Perhaps aaa.omniscient.com trusts
   aaah.donut.com, too.  But that doesn't help him because the CER has
   nothing in it even claiming that the connection is being created
   because of a redirect from aaa.omniscient.com, let alone proving it.

   -->(1)A major weakness with the redirect model is that the recipient
         does not even know who made the referral.

   Now consider the server discovery model. [email-masked] dials in to
   wondernet.net, and the wondernet AAA server, aaaf.wondernet.net, does
   a DNS lookup to discover that the AAA server for donut.com is
   aaah.donut.com.  What good does that do aaaf.wondernet.net?  How does
   aaaf.wondernet.net even know whether wondernet and donut have a
   business relationship?  If they do have a business relationship, then
   why is it so hard to configure aaah.donut.com into
   aaaf.wondernet.net's peer table?  So what good is peer discovery?

   -->(2)A problem with peer discovery is that a server doing it must 
         have an independent means of knowing what realms it may make 
         peer connections to.
      
   Assuming aaaf.wondernet.net does have enough configuration 
   information to feel comfy establishing a peer-to-peer connection with 
   aaah.donut.com, we still have the same problem with had with the 
   redirect model: How does aaah.donut.com know it's o.k. to receive a 
   connection from aaaf.wondernet.net?

   In either model, if a Diameter server receives a CER from a Diameter 
   node that is not hard configured into its peer table, then we need to 
   ensure that some form of peer-to-peer security is in place.  It 
   cannot assume that such a connection is IPsec protected.  So it must 
   insist on TLS.  But this is nowhere stated.

   -->(3)A Diameter node receiving a CER request from another Diameter 
         node that is not hard configured into its peer table MUST 
         reject the CER if it does not arrive on a TLS-secured transport 
         connection.
      
   Some may assume that the successful establishment of a TLS connection 
   provides sufficient warm fuzzies to both parties to the connection 
   for them to want to bring up a peer-to-peer link and transfer 
   Diameter messages over it.  I am not convinced that that is a 
   reasonable assumption except perhaps in some very constrained cases.  
   These constraints need to be fully described in the security 
   considerations section.
   
   -->(4)The limitations in the use of TLS to establish trust need to be 
         understood and clearly stated.

Requested change:

   I think the usefulness of the redirect and server discovery models 
   ought to be reexamined in light of the security problems they 
   introduce.  It may be that removing redirect and server discovery 
   from Diameter is the best solution.
   
   If the working group believes that redirect and server discovery are 
   really needed and still useful when constrained to operate securely, 
   then their use needs to the subject of a genuine security analysis.  
   These capabilities are not present in RADIUS and they greatly 
   complicate peer-to-peer security.  In RADIUS a node will only 
   exchange messages with other nodes with which it is configured to 
   communicate.  If Diameter introduces dynamic peer-to-peer 
   connections, a new trust model must be created or else the entire AAA 
   infrastructure is at risk.