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

Re: Granularity of authentication in swIPe



>Of course it is bound to the IP address, just as a TCP port number
>makes sense only in the context of an IP address. There isn't any way
>to get around this -- networks connect computers, not people. That

This is a crucial point, one that's been kicking around for some
time. I keep coming back to the position that in just about every
modern operating system I know of, the kernel (or its logical
equivalent) where the networking code resides has complete access to
every one of its applications. That is, there's little to be gained by
moving a cryptographic security mechanism with all its keys up to the
application since a corrupt kernel can still get at them anyway.

That said, the other major function of a kernel (protecting
applications from each other) isn't really provided in a UNIX style
networking environment, aside from the primitive and inadequate BSD
mechanism of allowing only root processes to bind to raw IP "ports"
and to low-numbered TCP and UDP ports.

Perhaps what we need for SwIPe or its successor are new mechanisms in
the UNIX kernel to manage access to the host-pair security
associations maintained in the kernel. E.g., there might be a
capability list that specifies which SAIDs may be used by which
processes. SAIDs created with a particular application-provided key
would by default be usable only by the process that created them (and
provided the crypto keys). Other processes on the same machine would
have access to the SAID only if the creating process were to grant it.

Of course, with the trend toward more and more single-user UNIX
systems, the historical importance of the kernel protecting mututally
hostile processes from each other becomes less important all the time.

Comments?

Phil





References: