[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 implemntation must be modified to use
IPSP with the key management you propose. 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.
My understanding was that the IP layer was selected so that the security
could be slipped into the protocol stack with alot of transparency. 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.
IPv6 may have an advantage here since they are defining a new protocol,
they also get to design a new service interface. The new service interface
MAY be more compatible with your goal.
You go on to say:
> There are very good reasons that the IPng directorate made the
> decision they did. I wouldn't discard the recommendation without
> extremely serious thought.
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.
Please do not confuse Kerberos with IPSP. Kerberos is an application layer
protocol, not a network layer protocol. Thus, it does not have to deal
with multiplexing at the transpot layer.
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 think that IPSP has many advantages, but in my opinion, it should not be
used (or abused) to provide application-to-application security.
Russ
Follow-Ups: