Re: CERT statement

>> What we need to concentrate on is secure systems that are not vulnerable 
>> to IP spoofing, as opposed to firewalls.

You're exactly right.  However, getting people to deploy real security
systems is nearly impossible.  My company sells a kerberos system, and
although everyone is saying they want security, nobody really
understands what this means, and as soon as we tell them that it
actually involves effort, they become far less interested.  Even
though I've seen companies get hosed because of lame security, the
people who matter aren't willing to commit.

I'm hoping that as firewalls begin to fall, that the CERT will stop
recommending half-assed solutions.  We'll have to wait and see.

		Marc

On Jan 26,  4:42pm, Marc Horowitz wrote:
> You're exactly right.  However, getting people to deploy real security
> systems is nearly impossible.  My company sells a kerberos system, and
> although everyone is saying they want security, nobody really
> understands what this means, and as soon as we tell them that it
> actually involves effort, they become far less interested.

To a former employer of mine, security meant using the word "security"
in as many reports as they could.  The management never committed
resources to it, and didn't seem to have a grasp of even the most
basic concepts of it, but as long as they said "security" lots of
times, they felt that they had it.

Unfortunately, this seems to be a fairly typical state of affairs
in many organisations.

						Ian.

Marc Horowitz says:
> You're exactly right.  However, getting people to deploy real security
> systems is nearly impossible.  My company sells a kerberos system, and
> although everyone is saying they want security, nobody really
> understands what this means, and as soon as we tell them that it
> actually involves effort, they become far less interested.

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.

Perry

On Thu, 26 Jan 1995, Perry E. Metzger wrote:

> 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.

Do you really need to authenticate every packet?  Isn't it enough to 
authenticate the party and perform a secure key exchange, then depend on 
the encryption (+ message authentication code for block ciphers) ?

-Thomas

Thomas Grant Edwards says:
> On Thu, 26 Jan 1995, Perry E. Metzger wrote:
> 
> > 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.
> 
> Do you really need to authenticate every packet?  Isn't it enough to 
> authenticate the party and perform a secure key exchange, then depend on 
> the encryption (+ message authentication code for block ciphers) ?

If things are merely encrypted, an attacker can garble them without
being caught -- I can "decrypt" random numbers into other random
numbers if I want.  Think of an attacker trying to sabotage the
transfer of a binary file and you'll see why you need authentication.

Perry

On Fri, 27 Jan 1995, Perry E. Metzger wrote:

> If things are merely encrypted, an attacker can garble them without
> being caught -- I can "decrypt" random numbers into other random
> numbers if I want.  Think of an attacker trying to sabotage the
> transfer of a binary file and you'll see why you need authentication.

You certainly need some kind of encrypted secure checksum (MAC) to ensure 
message integrity.  I don't think you have to go through the 
entire authentication of the principal.  (Though as V. Gligor keeps 
showing, even if you have a MAC at the end of your data, there are still 
some kinds of integrity attacks which are possible if you are not careful 
about how MACs and encryption is used).

Now if you are talking about simple denial-of-service (detected tampering
or traffic flooding), that is another more difficult story. 

-Thomas

Thomas Grant Edwards says:
> You certainly need some kind of encrypted secure checksum (MAC) to ensure 
> message integrity.  I don't think you have to go through the 
> entire authentication of the principal.

The techniques being talked about use keyed MD5, which the equivalent.

Perry

>> 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.  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.

		Marc

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