[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 Security Last Call Initial Questions (per user keying)

   Date: Fri, 31 Mar 1995 15:26:35 -0800
   From: Danny.Nessett@Eng.Sun.COM (Dan Nessett)
   X-Sun-Charset: US-ASCII

   P.S. Ted says this is easy, so perhaps he can consider this as a
   challenge :-). 

OK, here's a back of the envelope design, completely off the cuff.  I'm
sure there will be some issues which will need some more thought, but
it's a beginning.  I'll assume a BSD Socket's style interface, as it's
what I'm most familiar with.

    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:

struct seccon_info {
	uint32	SPI;
	int	transform;   /* Security transform, indexed by integer */
	int	len;	     /* Length of security transform specific data */
	char	data[];      /* Security transform specific data */
};

This structure intentially looks much like a "struct sockaddr"; for a
specific security transform, there might a more specific structure which
replaces the data field with some substrcture, much like "struct
sockaddr_in".

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.

    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.

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.

						- Ted