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

From: <[email-masked]>
Date: Tue, 12 Mar 2002 16:38:28 +0200

David,

I think someone raised a valid point that we may wish to
add text for the security implications of redirect.
Would that be sufficient, or are you looking for more?

John

> -----Original Message-----
> From: ext David Spence [mailto:[email-masked]]
> Sent: 12 March, 2002 00:08
> To: David Frascone
> Cc: Loughney John (NRC/Helsinki); [email-masked]; 
> [email-masked]
> Subject: Re: [AAA-WG]: Issue 303: Security model for peer 
> discovery and
> redirect
> 
> 
> 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.
> 
> 
> David Frascone wrote:
> > 
> > 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
> > 
> > On Monday, 11 Mar 2002, [email-masked] wrote:
> > > 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.
> > >
> > 
> > --
> > David Frascone
> > 
> >           Don't just do something !!! Stand there !!!
>

---

From: David Spence <[email-masked]>
Date: Tue, 12 Mar 2002 11:25:14 -0500

That would most definitely not be sufficient.  It only addresses one of my
points and quite inadequately at that.  For the redirect model, you would
also need to add text that says something like, "A Diameter node MUST NOT
accept a proposed connection unless one of the following conditions are
met."  And then you have to get the conditions list right.  One of the
conditions would be that you have a hard configured entry for the peer in
your peers table.  Another might be that you received a CER over a TLS
connection and the certificate met certain requirements which you also need
to specify somewhere.  In other words, there is no easy way out.  Yes, I
think peer-to-peer security can be fixed, but it will take some real work.