Re: swIPe

["Perry E. Metzger" <perry@imsi.com>]

Matt Blaze says:
> Well, if by swIPe you mean the standards-track IP security protocol,
> quite a bit.  I'm not going to the next IETF meeting (perry?, phil?)
> but I understand that swIPe and friends have mutated into something
> that is very close to becoming an RFC.

True.

> Key management is another story, with no general agreement as to
> what the requirements even are.

Less true; there are multiple proposals, but none of them meet my
internal standards on what is needed :-)

> My own feeling is that more experience is needed with network-layer
> security in general before the problems and tradeoffs of key managment
> in heterogeneous networks will emerge with any clarity.

I would partially agree. We do have some actual real world experience
with one key management and authentication system -- Kerberos. Its not
sufficient, but it does provide a lot of interesting lessons. In
particular, it has a distinct advantage over most the the currently
proposed key management systems in the IETF: it is actually possible
to write secure applications with Kerberos. (This is not as bad as it
sounds; there are still ways to use the proposed key management
systems (for setting up encrypted tunnels as an example) but these
uses are more limited.)

> If you mean swIPe, the protocol described in Ioannidis and Blaze's
> draft RFC of last December, not much.  There's an implementation
> floating around (I think on the ucb ftp server), but I don't know
> of anyone who's actively deploying it outside of closed systems.

Actually, swIPe the implementation has been ported to three systems
(largely berkeley clones) and is being actively sold as part of the
TIS firewall product. However, its future with its current packet
format is obviously limited. swIPe the packet format is quite dead,
but swIPe the implementation will probably be hacked to support the
IPSP protocol, whatever it ends up being in the end.

> Now would is a very good time to play with this stuff, particularly with
> an eye toward understanding what the key management requirements are.
> Right now the future internet cryptographic security architecture is wide
> open, but that window is starting to close.

Quite true.

Perry