[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Security Last Call Initial Questions (per user keying)
o How will the SPI and security context information be passed from both
connecting and accepting processes to the IP implementation?
>There are two cases. The first if you need to set need to set the
>security context information to be used for a new TCP connection, or for
>UDP packets. In this case, you simply use a new ioctl or setsocketopt
>to set new security context information, which will override the
>host-specified default. This would be done before the accept() or
>listen() call. The structure that would be passed to the socket might
>look something like this:
We also must make sure that if the default is to not use security per
the user but does want to now use if for a specific application that it
is possible without altering the default to not use security by this
user.
There is also the case that the sender has provided security to a listen
or accept and the user has decided to not use security for that
application. In this case the default is use security but an
application has decided to not use security. This also involves
rejection or acceptance of the IPSP payload at the internetwork layer
too, which brings us to policy and the various combinantions of MAY or
MAY NOT USE security in an implementation.
>The second case is if you want to change the security context used with
>an existing TCP connection. This is much harder, because of the
>syncronization issues. The way I'd suggest handling this is to add the
>new security context information (using the above structure). At this
>point, the implementation will accept packets with either the old or the
>new SPI (although it will only send packets using the old SPI). The
>application will is responsible for confirming that the new security
>context is established at both sides. Once this has happened, the
>application uses another ioctl or setsockopt to revoke the old security
>context.
I am not clear on what you "define" as the context to be changed above?
So I will wait to respond.
o How might this information be derived from the key management protocol?
Any choice here can be used, Photuris, Kerberos, etc.
>The key is derived from the key management protocol; the only other
>information that is needed is for the kernel to allocate a unique SPI.
>This can be done by having the kernel allocate and fill in the SPI field
>of the structure, and the application would then pass the SPI to the
>other side, which would specify it in the structure.
Why do you believe this needs to be done in the kernel? It costs to
cross that kernel boundary.
>Anyway, that's the basic idea --- there are obviously a lot of details
>that needs to be fleshed out. But you just wanted a proof concept that
>it was in fact possible; hopefully this is what you were looking for.
I think we need a bit more than this but it starts the discussion.
thanks
/jim