1995-01-27 - Re: CERT statement

Header Data

From: “Perry E. Metzger” <perry@imsi.com>
To: Marc Horowitz <marc@cam.ov.com>
Message Hash: 833fab05a686d7eb9cfed349761c2d22a25d17911781ca9aa2f193630977271c
Message ID: <9501270023.AA17883@snark.imsi.com>
Reply To: <9501270011.AA07672@dun-dun-noodles.cam.ov.com>
UTC Datetime: 1995-01-27 00:23:19 UTC
Raw Date: Thu, 26 Jan 95 16:23:19 PST

Raw message

From: "Perry E. Metzger" <perry@imsi.com>
Date: Thu, 26 Jan 95 16:23:19 PST
To: Marc Horowitz <marc@cam.ov.com>
Subject: Re: CERT statement
In-Reply-To: <9501270011.AA07672@dun-dun-noodles.cam.ov.com>
Message-ID: <9501270023.AA17883@snark.imsi.com>
MIME-Version: 1.0
Content-Type: text/plain



Marc Horowitz says:
> >> Kerberos per se isn't sufficient to defend against session hijacking
> >> attacks, you know. The situation in question is really insidious and
> >> requires packet-by-packet cryptographic authentication.
> 
> No, but kerberos or something like it is necessary.

Well, sort of. A key management system that operates sort of like
Kerberos' is necessary. However, thats really far from
sufficient. Most Kerberized protocols authenticate only at the
beginning of the session -- very very hijackable.

> And I think I can safely say that anything which really defends
> against TCP sequence spoofing or hijacking attacks will be more
> invasive and require more effort than kerberos, not less.

Oh, hardly the case -- in fact in the architecture of the system I'm
developing things are actually slightly easier than in the kerberos
situation. Invasive I'll agree with -- encrypted/authenticated IP
requires kernel mods. However, they can be made fairly painless.

I'll point out, by the way, that one of the major problems with
kerberos is just bad documentation and difficult build tools.

Perry





Thread