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

From: <[email-masked]>
Date: Mon, 11 Mar 2002 09:00:37 +0200

Hi all,

http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#303

Issue 303 is a quite a big change, in my opinion.  I am somewhat
hesitant about tackling this, so I thing the WG needs to discuss
this.  Security is, of course, extremely important.  Does the
workgroup see this a good solution? 

I'd appreciate comments on this.

thanks,
John

PS - the requestion change is:

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.

---

From: David Frascone <[email-masked]>
Date: Mon, 11 Mar 2002 06:02:32 -0600

My vote would be to reject this issue.

But, to address the possible security issues, perhaps we should allow
implementations to decide whether they allow redirects.  (In other words,
server X might not allow redirects from realm Y)

As far as server discovery goes . . . that smells like an implementation
issue. . . . .  

-Dave

-- 
David Frascone

          Don't just do something !!! Stand there !!!

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Mar 2002 04:12:43 -0800

security should not be an "implementation issue."  authentication
of a referred host by the host which receives their request would
seem to be pretty basic security.

on first blush, it seems to me that there are only three ways to
solve this (but it's still early here)

  o trusted referrer gives referee a signed cert to be handed to
    the host to which they refer them

  o trusted referrer acts as a relay/proxy, with all the kink
    that gets us

  o never talk to folk with whom you do not have a configured
    relationship

oh, and then there is hanging your butt out there in the breeze
waiting to be killed

randy

---

From: David Spence <[email-masked]>
Date: Mon, 11 Mar 2002 17:07:43 -0500

I raised a number of specific security concerns in issue 303 and I don't 
think it is responsible to dismiss them summarily.  I think each 
deserves some kind of response.  I am actually very concerned that 
peer-to-peer security may be worse in Diameter than it is in RADIUS.  
RADIUS has real peer-to-peer security -- the shared secret!  Yes, I know 
it's real bad security.  But at least there's something real about it.  
Diameter may be run with no security -- and the server won't even know.

Consider IPsec.  The underlying problem with IPsec is that it isn't easy 
for a "Diameter node" (server or client process) to verify that IPsec is 
being used.  This weakness can be exploited in a number of ways.  Issue 
303 mentioned one of them.  If a peer-to-peer connection is being 
established dynamically due to peer discovery or the action of a 
redirect agent, it is rather likely that an IPsec tunnel does not exist.  
(If it did, you wouldn't need peer discovery or a redirect agent.)  But 
I believe that the problems of relying on IPsec run deeper than that.

Example 1:

   Consider the case of the ISP Fastgrowth.net.  Fastgrowth has 12 NASes 
   named nas01.fastgrowth.net through nas12.fastgrowth.net.  Their 
   Diameter server is named aaa1.fastgrowth.net.  The configured peer 
   table for this server contains entries for nas01 through nas99.  
   IPsec is used for peer-to-peer security.  When a new NAS is 
   installed, the network administrator assigns it a name in the range 
   nas01-nas99 and sets up an IPsec tunnel for it.  Now an attacker in 
   Elbonia wishes to attack Fastgrowth with the aid of a Diameter Attack 
   Client he's cobbled together.  He names his client 
   nas13.fastgrowth.net (on a hunch) and attempts to bring up a 
   peer-to-peer connection with aaa1.fastgrowth.net.  As luck would have 
   it, the name he chose is in aaa1's peer table.  Of course there is no 
   IPsec tunnel, but aaa1 doesn't know that.  So aaa1 merrily brings up 
   a connection with the impostor.  That attack would have been much 
   harder to pull off with RADIUS because of the burden of having to 
   guess the shared secret.

So much for IPsec.  At least TLS doesn't have that problem.  With TLS, 
you know you're secure.  Maybe.

Example 2:

   A group of small, regional ISPs spread across the northern U.S. from 
   Lake Wobegone, Minnesota all the way to Blight, Idaho, has 
   established a roaming consortium called the Northern Alliance.  
   Consortium members establish peer-to-peer connections between their 
   Diameter servers as needed using peer discovery.  For security, they 
   use TLS.  Since most of their administrators are not security 
   experts, they want to make sure they get it right.  They choose 
   Verisign as their CA.  Now a group of outlaws in Wyoming starts up a 
   small ISP of their own called Blackhats.net.  They do not join the 
   Northern Alliance.  But their leader, Jesse James, applies to 
   Verisign for a certificate for their Diameter server.  Now, without 
   bothering to join, they can send peer-to-peer connection requests to 
   Diameter servers throughout the Northern Alliance.  When the Diameter 
   server for Sittingducks.net, the Lake Wobegone ISP, receives one of 
   these requests, it examines the tendered TLS certificate and reads 
   the fine print, which says, "To whom it may concern: We, Verisign, 
   have verified the identity of one Jesse James by comparing his face 
   to the photographs on the wall of the Post Office down the street.  
   We are confident that the applicant for this certificate really is 
   Jesse James and that he really is a principle of the Wyoming 
   corporation Blackhats.net."  So they merrily bring up the connection.  
   Again, the attack would have failed with RADIUS because Jesse would 
   never have guessed their shared secret "happytrails2U".
   
Yes, I know the Northern Alliance could have done better.  But we 
haven't exactly helped them by explaining in our Security Considerations 
how TLS should and should not be used to secure peer-to-peer 
connections.

Now here's the real problem.  The real problem is that Diameter, when 
used to support roaming in a multi-domain environment, relies on 
transitive trust.  I trust the Diameter messages sent by all the good 
buddies of my good buddies because I trust my good buddies' trust.  This 
means that if a successful peer-to-peer attack can be launched against 
any of the thousands of my buddies' buddies, then I am vulnerable.

Example 3:

   The GrockPass Roaming Broker decides to upgrade the GrockPass 
   Alliance from RADIUS to Diameter for all inter-domain AAA requests 
   because of Diameter's superior security.  GrockPass uses TLS security 
   and they themselves run the CA for the alliance so there won't be any 
   funny business.  Only certificates signed by GrockPass are accepted 
   by alliance members.  One day Maxwell Smart, the system administrator 
   for GoodVigilance.net, notices that their Diameter server has 
   received a very large number of failed authentication requests from 
   GrockPass affiliate Laxnet.com proxied through GrockPass.  The failed 
   authentication requests all come from nas13.laxnet.com and appear to 
   be an attempt to mount a dictionary attack against the PAP passwords 
   of the GoodVigilance dialin users.  Max calls up his counterpart 
   Dudley Hopewell at Laxnet.  "Gee," Dudley says, "We don't even have a 
   nas13."  Dang those Elbonians.
   
In this example, all the good vigilance of GoodVigilance and GrockPass 
could not protect them.  That is why, if you are designing a 
multi-domain protocol, you SHOULD NOT make it rely on the intelligence 
and vigilance of all the domains' network administrators.  Because even 
if an administrative domain believes in the intelligence and vigilance 
of its own administrator, what about all the other stupid, lazy 
administrators out there?  At least let the vendors help out by making 
the application verify the security directly wherever possible.  And 
where it's not possible, make sure the vendors understand the Security 
Considerations well enough to insert plenty of BIG BOLD WARNING MESSAGES 
in their GUIs to give their customers a little help.

In conclusion, Diameter has the following peer-to-peer "features" that 
RADIUS lacks.

   1) Dynamic peer-to-peer connections (ones that are not 
      preconfigured).  Both peer discovery and redirect agents require 
      this.
      
   2) Non-verifiable peer-to-peer security associations (IPsec).
      
   3) The ability, by abusing TLS, to bring up authenticated, but 
      unauthorized peer-to-peer connections.

We need to be sure Diameter nodes can implement these features securely 
or else remove them.  The two questions in each case are, how do I know 
I'm authorized to establish this connection and how can I authenticate 
the peer?  If we can't answer these two questions satisfactorily, we 
should stick to configured peers with configured shared secrets.

---

From: David Frascone <[email-masked]>
Date: Mon, 11 Mar 2002 17:43:41 -0600

> seem to be pretty basic security.

I didn't mean to imply that I was comfortable blowing off security.  What
I meant was, for different scenarios, whether or not to allow redirects
and/or discovery should be a configurable setting (and therefor an
implementation issue)

For example, within your home realm, having your home server redirect you
to a server with better load charastics would be a benefit.  Now, for the
really paranoid, a server could be configured to only accept redirects
after a SA with the redirecting host was verified.  (via TLS or IPSEC)

Also, when a server is in a foreign realm, and is doing peer discovery, the
entire realm is possibly suspect.  So, any server found, whether by discovery
or by pre-configured address is still possibly an "evil" machine.  So, 
discovery in this case does not add any danger, IMHO.

>     the host to which they refer them

Heh . . I guess I should have read this before I preposed the same thing :)

> oh, and then there is hanging your butt out there in the breeze

All of these issues really depend on the scenario . . . that's why I voted
*no* to dropping the ability to do redirects and discovery.  I think they
are useful tools.  But, I also agree that they are potentially dangerous.

Perhaps we should (instead of killing the features) add a few paragraphs 
outlining the security threats, and how to avoid them, depending on the 
situation.

-Dave