ascend.multilink.ppp.txt

`Date: Wed, 10 Feb 1999 15:08:50 -0800  
From: David Schwartz <[email protected]>  
To: [email protected]  
Subject: Security problems in ISDN equipment authentication  
  
  
A security flaw is probably still present in Ascend's multilink PPP  
implementation over ISDN. Due to its fundamental nature, it's probably in  
other ISDN hardware as well.  
  
Ascend determines whether to bond a new incoming PPP connection with a  
previous connection based upon the 'endpoint identifier'. As I recall, they  
claimed that they had to do this because they had to decide whether to bond  
or not _before_ they received any other authentication information.  
  
Most ISDN routers use their Ethernet hardware address as their endpoint  
identifier. I'm not sure what modems and T/As use. However, since the  
endpoint identifier is specified by the other end, it is fundamentally  
insecure to rely upon it for a security decision, such as whether to bond to  
an existing PPP connection.  
  
The way we discovered this was during WebRamp beta testing, when the  
firmware had an interesting bug. It seems that every WebRamp sent the same  
endpoint identifier! Sure enough, if two WebRamps ever connected to the same  
Max or TNT, they'd get bonded to each other and both would fail to send any  
(futher) data reliably.  
  
Ascend insisted that the bug was in the WebRamp (it was sending an invalied  
endpoint ID). We responded that while there was a bug in the WebRamp, it was  
exploiting a security flaw in the Ascend. Anyone can, in principle, specify  
any endpoint identifier that they wish. Ascend simply got WebRamp to fix the  
flaw, and to my knowledge, this weakness still exists. Anyone who knows your  
endpoint identifier can bond to your PPP link. Anyone who you have ever  
connected to with your ISDN equipment knows your endpoint identifier, and  
you cannot easily change it.  
  
To an extent, the problem is fundamental. If you aren't using PAP or CHAP,  
but instead use a text 'sign on' form of authentication, but are bonding  
multiple connections, what means does the other end have to determine  
whether to bond to an existing connection when it receives a new one? But we  
had this problem even with PAP or CHAP enabled -- I'm not entirely sure why.  
  
DS  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 12 Feb 1999 09:14:12 -0800  
From: David Schwartz <[email protected]>  
To: [email protected]  
Subject: PPP/ISDN multilink security issue - summary  
  
  
My thanks to the many people who responded to my post about security issues  
when terminal servers make the decision about whether to bond two physical  
connections into a single network connection (multilink PPP).  
  
Ascend has stated (unofficially) that their implementation was at one point  
insecure, and relied upon the TEI or EDO (endpoint identifier) to make the  
decision. This is in violation of standards. They state that their  
implementation has been secure for about three years and will not bond two  
connections together unless the authenticate with the same username.  
  
If multilink PPP is properly implemented, it should make two connections  
_eligible_ to be linked together if and only if their TEIs match. However,  
it must be prepared to not link them if they later identify (by PAP or CHAP)  
for different accounts.  
  
The RFCs state, according to Jeff Mcadams <[email protected]>:  
  
  
The Endpoint Discriminator Option represents identification of the  
system transmitting the packet. This option advises a system that  
the peer on this link could be the same as the peer on another  
existing link. If the option distinguishes this peer from all  
others, a new bundle MUST be established from the link being  
negotiated. If this option matches the class and address of some  
other peer of an existing link, the new link MUST be joined to the  
bundle containing the link to the matching peer or MUST establish a  
new bundle, depending on the decision tree shown in (1) through (4)  
below.  
  
To securely join an existing bundle, a PPP authentication protocol  
must be used to obtain authenticated information from the peer to  
prevent a hostile peer from joining an existing bundle by presenting  
a falsified discriminator option.  
  
  
The problem is, it seems that in some cases the router needs to do certain  
things one way if it's going to bundle the two connections together and  
another way if it's not going to, and it may need this information _before_  
the new connection has authenticated:  
  
Dennis Kavanaugh <[email protected]> states:  
  
  
Sadly, the real problem, IMHO, is in the Multilink PPP spec; if a vendor wants to  
conform to the spec, they must allow this to happen. I spent quite a bit of time with  
numerous vendors trying to explain the inherent vulnerabilities in the existing spec,  
but they didn't seem to understand or be bothered by the potential problems.  
  
The spec covers any type of MLPPP connection, be it dial-up ISDN (i.e., T/A), multiple  
async, or Brouter. Both ends must understand what can be done, and take steps to ensure  
they are providing as much security as they feel they need for the given situation.  
It's just another case where poor configuration can result in poor security.  
  
In reality, the resulting session when a hijacked session bonds with a legitimate  
session is unusable. Sort of 'security by unusability', if you don't count the DoS.  
  
  
The unusuability occurs because compression is usually in use, and the  
compression breaks when you only have part of a bundle.  
  
It seems that it is possible to do things right, but there are probably  
numerous implementations that incorrectly bond two connections with the same  
identifier even if they authenticate for different accounts. I still  
wouldn't want anyone else to know the Ethernet hardware address of my ISDN  
router.  
  
David Schwartz  
<[email protected]>  
  
`