[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: key management
"Housley, Russ" says:
> You prove my point. You say:
>
> > ..., it doesn't, although it does require that the transport layer
> > have the ability to tell the network layer which SAID to use.
>
> This means that EVERY transport layer implementation must be modified to use
> IPSP with the key management you propose.
Yes. It has to be modified. So what? The modifications are very small
and hardly onerous. If you want to use different SAIDs with different
sockets, which is without any real doubt a requirement, the layer
handling the sockets has to know how to specify an SAID.
Paraphrasing from "The Elements of Networking Style", layering is
supposed to be a tool, not a straight-jacket.
> The whole reason for placing the security protocol in the IP layer
> is lost if we have to modify the consumers of IP services to be IPSP
> and IKMP aware.
That is not the case. Part of the purpose as I perceived it was to
make sure that every application didn't have to implement a new
protocol or implement the same one over and over again. Part of the
purpose was to help provide immunity to traffic analysis. Part of it
was to provide the ability to build secure tunnels between insecure
networks. Part of it was so that (being Unix-centric for a moment --
other OSes have analogs) an ordinary "write" system call would end up
doing the "right thing" without having to have the application deal
with the encryption and authentication. Part of it was indeed so that
existing *applications* could get some authentication added without
needing to do any work. However, I don't recall anyone ever saying
that we should cripple the functionality so that we wouldn't have to
add a few dozen lines of code to the TCP and UDP implementations.
Those are, by the way, what you mean when you say "transports".
> My understanding was that the IP layer was selected so that the security
> could be slipped into the protocol stack with alot of transparency.
Yes, thats true. Very small changes need to be made to take advantage
of the work being done at the network layer, which is indeed where the
bulk of the protocol work is. The protocol only needs to be specified
at the network layer, too, since the operation of selecting a
particular SAID for a particular socket is an OS dependent
operation. That doesn't mean you don't want to be able to do it, however.
> If IPSP has the same interface as IP, then none of the consumers of
> IP service need to be modified, although they do need to be relinked.
My applications, which are consumers of IP service, won't even need to
be re-linked if I choose not use the new features. However, I don't
see the need to add a piddling few lines of code in to other portions
of the stack onerous. My intention is to change the interface to IP to
allow a (possibly null) SAID to be specified by the higher
layers. I'll have to change about a half dozen places where that call
is made, and then I'm done. Any transport that wants to be able to
specify SAIDs will have to have a little more work done to store them
along with the control block for a given socket and know to specify
that SAID when calling IP -- not a big deal at all.
> I have given this alot of thought. In fact, I have been involved in
> security protocol design efforts since 1986, and this issue comes up in
> each new effort.
Kerberos works today. Its the only thing widely deployed that does. I
trust experience over "alot of thought". Kerberos has taught us that
having our key management system give us good per user (or user-like
entity) authentication and key management is a very good thing.
> Please do not confuse Kerberos with IPSP.
We are talking about IKMP, not IPSP. Please do not confuse that
portion of the discussion.
> Kerberos is an application layer protocol, not a network layer
> protocol.
Kerberos is a key management and authentication system. It does
nothing about encrypting packets. The two are orthogonal. I'm
mentioning that if you want to layer something that would provide you
with the ability to, for instance, build authenticated and encrypted
applications on top of IKMP/IPSP, you will need to provide at least
Kerberos's level of per-user key separation. That means you will need
to be able to set a SAID per socket. The IPSP layer has to be able to
support this, but thats not what we are discussing (or at least, not
what we were discussing).
> If you want to protect traffic from application process to application
> process, then I suggest you abandon IPSP and work on a security protocol
> that lives in the application layer or a security protocol that lives in
> the transport layer (and applies the security before multiplexing).
I disagree. Why build a new mechanism when a perfectly good one
exists? IPSP does everything I want as a bottom layer, and I see no
reason to build a new mechanism into each and every transport that
does what IPSP does. Its very simple to just allow the transports to
specify what SAID should be used, and then suddenly IPSP does exactly
what I want.
The implementation I'm working on, which will be free, is going to
have this functionality.
> I think that IPSP has many advantages, but in my opinion, it should not be
> used (or abused) to provide application-to-application security.
If all we wanted to do was to provide the ability to produce secure
tunnels between insecure networks, we would need no key management at
all -- just use sneaker-net or use PEM or PGP to mail new keys. If you
want to do anything interesting in security, you have to be able to
build secure applications -- like secure file systems or remote login
programs. Without that, none of this is interesting.
References: