Date: Wed, 10 Feb 1999 15:08:50 -0800
From: David Schwartz <davids@WEBMASTER.COM>
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