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
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
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
participants (4)
-
Ian Farquhar -
Marc Horowitz -
Perry E. Metzger -
Thomas Grant Edwards