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

Re: Draft IPv6 Security API for BSD Sockets




Steve Bellovin says:
> I'm not very happy with some aspects of the draft.

Nor am I, as an implementer, frankly. At this point, I've been
ignoring the suggested API for my IPv4 code and I'm still
experimenting with what seems right.

> The latter is easier to explain.  I don't think that, in general,
> it's at all a good idea to send errors to a security-aware application
> simply because bogus (or damaged) packets are received.

Nor do I; my current design makes reporting of such things the
responsibility of system-wide security services and takes away the
task of dealing with them from applications entirely.

> I'd suggest a more tunable approach -- the
> process specifies a threshold, which defaults to infinity, for
> errors; when the the threshold is exceeded, a process-specified
> signal (or maybe SIGSECURITY or SIGHACK) could be raised.

Frankly, I'd prefer to leave this to a security daemon and
(indirectly) to the syslog facility. Applications are rarely if ever
in a good position to deal with such things, and its rare that such a
thing is something that the application cares about more intimately
than system administration. Also, putting this in application-land
means that you end up with dozens of different tuning mechanisms for
such reporting. I'd rather have it in just one place so the system
administrator might actually be able to make use of the data!

> My problem with the mechanisms for specifying security levels is that
> I think the proposal is too low-level.  It isn't clear to me that
> setsockopt() is the best way to proceed.

At the moment, I'm still experimenting with what seems best for
this. Whatever I choose is going to end up wrapped inside a library
call anyway, so I'm somewhat agnostic as to the specific
method. Beyond this, however...

> This becomes more apparent when we look at the next
> requirement, which is mentioned in the draft:  per-user SAIDs.
> 
> My mental model for this function is a Kerberos-like interface.  (There's
> a lot more involved in doing it right than just Kerberos, but I won't
> go into that now.)  The user process obtains some credentials for
> a connection; these credentials are bound to a pair of SAIDs, one for
> each end.  These credentials must then be passed to the kernel for
> use with one or more IP connections.  But obtaining these authorizations
> is not something that's easily done in the kernel.  A Berkeley-like
> kernel could, in principle, contact a credentials daemon on behalf
> of the current user, if no explicit credentials are supplied; that's
> much harder with streams, since a streams module does not have access
> to the user's u. or proc structures, and cannot easily sleep().

My design uses a credentials & key negotiation daemon that establishes
kernel security association structures at the request of an
application -- it then passes these structures to the application via
the same mechanism currently used to pass file descriptors among
unrelated processes. This allows the mechanism to leave the structure
completely opaque to the normal user process but allows the key daemon
to arbitrarily fiddle with the innards of the association.

My objective is quite explicitly to permit IPSP to be used in a very
kerberos-like manner.

> Note that my model supports host-pair SAID granularity as well.

Same here.

> I'm rambling a bit, and I'm probably not being very clear.  I'd like
> to hear other comments.

The stuff you are discussing thus far is very reminiscent in certain
ways of what I've already decided on for my prototype, so I'm
obviously not going to argue too strenuously. The need to support
per-socket SAIDs is clear; it is also necessary to permit the tagging
of routes with SAIDs to set up secure tunnels. 

Perry


References: