Negotiating Security Services
With the uncontrolled explosion of incompatible security mechanisms
available today comes a significant, unaddressed, problem of how two
machines can choose a suite of mechansisms for a particular type of
communication.
The degrees of freedom in the problem include the algorithms used,
modes of the algorithms, where the services
Why You Must Consider Protection Suites, Not Individual Mechanisms
There are several reasons why you should
- insecure
- harder to manage
- more overhead
The Need for System-Wide SPIs
There is currently a push in the IESG to make a SPI local to a particular
transform. This is a huge mistake. As noted above, the transforms that
are being applied all over the place are NOT independent. Since we must
treat a stack of services as a whole, but have to treat each SPI as
transform-specific value, we are forced to introduce a notion of "meta-SPI"
for no good reason.
Allowing a security manager (e.g., a negotiation server) to manage the
SPI space for all transforms is a much cleaner solution. There will be
less duplicated functionality in each transform, and the security manager
will be simpler as well.
Links to ISAKMP and Related Resources
ISAKMP Documentation
The latest Oakley Draft (Draft 1)
The latest ISAKMP/Oakley Resolution Draft (Draft 1)
ISAKMP Implementations
SKIP - The S
Group Key Management
GKMP Architecture
GKMP Specification
Skeme
Secure DNS
The most likely short-term route for certificate management.
Quality of Service Research
I believe that security service negotiation should be simply an aspect of
overall QoS negotiation, and I'm working toward that end. Here are some
pointers to current QoS work.
Jeff Turner
sjt@cs.utah.edu