[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[2]: key management
Perry:
> > 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.
I am not trying to put a straight-jacket on anyone or on any design.
Rather, I am trying to preserve some layer independence. Layer
independence has allowed many experiments to proceed on the Internet
because they could take advantage of the services provided by existing
protocol layers.
If one layer must provide parameters that it would not otherwise care
about, then the layers are not indpenedent. In your case, the transport
layer (be it TCP, UDP, TP0/RFC1006/TCP, or any other) must pass a SAID to
the IPSP layer. From other messages, I get the feeling that the
application layer is passing the SAID to the transport, although you have
not stated this explicitly. This means that the transport doesn't care
about the SAID, and this leads me to believe that the security service that
you want is being applied at an in appropriate place.
I simply restate my opinion: user-keyed security services should be
applied in a layer that is easily mapped to the user. And, that is not the
network layer.
> > 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".
Gee, I do not remeber you at the meetings where the IPSEC charter was
drafted. We did the first draft at the Washington, DC IETF meeting. I'm
glad that you find the IP security service so useful, but I can guarentee
you that traffic analysis was not one of our reasons. In fact, the network
layer is too high in the protocol stack if you are really concerned about
traffic analysis.
> > 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.
I agree with almost everything you say in the paragraph. However, you must be
careful that to implemntations with different ideas of key granularity do not
cause each other problems. For example, suppose an IPSP implementation that
uses one key for the tranmission of all data between two hosts trying to
communicate with another IPSP implementation that uses a different key for each
TCP connection. If they only have one open TCP connection, everything works.
Then, when a second (differently keyed) TCP connection is established, the first
host may throw away the first key. After all, only one key is needed and the
"newer" one was kept.
The elements of procedure associated with the security association management
are very important to interoperability. Different models can lead to big
failures.
> > 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.
I could not disagree more. Automated key management is needed for any
widely deployed security protocol.
Russ
Follow-Ups: