[9575] in bugtraq

home help back first fref pref prev next nref lref last post

Re: PPP/ISDN multilink security issue - summary

daemon@ATHENA.MIT.EDU (Josh Bailey)
Mon Feb 15 01:27:50 1999

Date: 	Sun, 14 Feb 1999 04:29:36 +0000
Reply-To: Josh Bailey <jbailey@ASCEND.COM.AU>
From: Josh Bailey <jbailey@ASCEND.COM.AU>
X-To:         Marco S Hyman <marc@SNAFU.ORG>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <4728.918892997@dumbcat.snafu.org>

-----BEGIN PGP SIGNED MESSAGE-----


[Disclaimer: I'm not speaking for Ascend officially.]

Hi Marco;

Was about to reply when I saw you got there first. :-)

I believe from some discussion here that your (2) was precisely the case
(I've not been with Ascend for that many years, so hadn't had personal
experience with this problem).

One of the regression tests I regularly run includes these sorts of
conditions - including races where two channels coming from the same TA
arrive simultaneously both trying to authenticate. Personally, my
experience has been that these sort of things are dealt with thoroughly.

On Sat, 13 Feb 1999, Marco S Hyman wrote:

> David Schwartz writes:
>  > 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.
>
> 1) TEI is an ISDN thing.  Perhaps you have confused the ISDN term TEI
>    (Terminal Endpoint Identifier) with the PPP term Endpoint Descriminator.
>    They are NOT the same thing.  The PPP code knows nothing about the ISDN
>    TEI.  It can't as PPP is not dependent upon ISDN.
>
> 2) Ascend code would add a link to an existing bundle if the Endpoint
>    Descriminator matched AND the link was authenticated.  The bug
>    was that the authenticated user did not have to match the bundle's
>    user.  Yes, that was incorrect.  Yes, it would cause a DoS.  However,
>    since the caller causing the DoS had to be authenticated (and was
>    logged) it was easy to see who was causing problems and trivial to
>    disable that login.  But it's good to hear that the problem has
>    been fixed.
>
> // marc
>

- --
Josh Bailey (mailto:josh@ascend.com)

Principal Engineer (Access), APAC            Voice:        +61-3-9656-7000
Ascend Communications, Inc 		     Fax:          +61-3-9656-7006
Level 38, ANZ Tower, 55 Collins St           Mobile:       +61-417-128-921
Melbourne, Australia                         PGP:    SEND FILE jbailey.asc




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBNsZRMcyBE5tx+aP1AQF+/gL+PR18jYNOgLuqCc0uxSoVGf2mj982stX2
x/55u9q8IBManTm1tXnuYThQ8neM6XrkXS21fekEoC/7Bi38clZuXAqrN1dzJSdU
sEmKyQvlEyd46eZBCmZiQx8sON5lWYMq
=8YTj
-----END PGP SIGNATURE-----

home help back first fref pref prev next nref lref last post