[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: manual keying and IPSEC conformance
Perhaps "back door" was too strong of a statement, but manual keying
might present a security risk if an uninformed user set it up
incorrectly.
We must make some form of KM is a MUST for interoperabilities sake, and
if you do not do so with ISAKMP, then we must manual keying a MUST.
My point though, was that I do believe that an implementation that does
not support manual keying (either turns it off, or doesn't even have the
code for it) should still be considered IPSec-compliant.
>----------
>From: Dan.McDonald@eng.Sun.COM[SMTP:Dan.McDonald@eng.Sun.COM]
>Sent: Thursday, August 21, 1997 5:52 PM
>To: Roy Pereira
>Cc: ipsec@tis.com
>Subject: Re: manual keying and IPSEC conformance
>
><SNIP!>
>> I know that most of our clients do not want a back door like manual
>> keying in their security product.
>
>One thing I have a terrible time understanding is why people think manual
>keying will make their systems LESS secure. The only gain in security you
>get by disabling manual keying is STO, and that's because your adversary has
>to somehow gain access to the machine state by other means than a manual
>keying interface.
>
>I'm not saying manual keying should be an operation open to every user on a
>system, at every privilege level. It's most definitely a privilege;
>root-level on UNIX, and requiring its own privilege class on an MLS system.
>And if you're on a system that has only one privilege level (PC of some
>kind), then machine state is probably not difficult to obtain anyway.
>
>If anything, manual keying is the only truly secure method of key exchange.
>Two ultra-paranoid parties figure out in a locked room what the key is, they
>go home and _manually_ add it to their respective systems, which they have
>locked up and guarded with shotguns, dogs, etc. The problem reduces to the
>key strength of the algorithm in question.
>
>Now granted, the current suite of algorithms and key exchanges are such that
>the strength of the key exchange dominates the strength of the algorithms
>being used, but that doesn't have to be the case. Hell, I may want to use
>2048-bit El Gamal on my traffic w/o having to secure it with a 4096 exchange.
>Sure it'll be slow, but it'll definitely be secure.
>
>---
>
>On another note, thanks to those who pointed out that there is a difference
>between manual keying, and hooks for other KM schemes. In my haste to get
>out my first note, I failed to make that distinction.
>
>Noting that distinction, however, I will say that if you have hooks for other
>key mgmt. schemes, it shouldn't be too terribly painful to use the same hooks
>to attach some sort of user-interface to your SADB/Key-Engine/etc. Even if
>your hooks are inside a protection boundary, a shim that crosses that
>protection boundary shouldn't be difficult to construct.
>
>I offer the BSD Routing Socket, and that the route(8) command in BSD is just
>a command-line interface to said routing socket, as an example.
>
>Dan
>
Follow-Ups: