[cap-talk] network level designation and authorization, meta

[Ian G]

coderman wrote:

>>As I read the whole discussion, the focus is on protecting data on the
>>wire (air).  I have to admit that I think of this topic as pretty much a
>>solved problem (e.g. SSL).
> 
> 
> i guess i agree in the sense that SSL (with self signed certs) could
> solve this problem, just like openvpn uses SSL to solve the problem of
> privacy between IPv4/IPv6 endpoints.

On this particular point, I would wave the "rude"
flag here and disagree!

If the focus is on protecting data on the wire,
I'd say this is an *unsolved* problem.  There
are well known brand names in that space, but
they aren't doing much good.  (Old debate...)

Just to take the above example:  openvpn over
SSL.  Last I understood this, VPNs bifurcated
into those that were browser/SSL pretend-VPNs
(successful but limiting) and those that were
in kernel, IP packet layer ones.  Now, this
latter group more generally use a datagram-
based protocol.  In contrast in OpenVPN, if
it is layered over SSL - that's a connection
based protocol - so we have made a compromise
right there.

Indeed the reason the browser/SSL VPNs and
OpenVPN exist is because it is so hard to do
it at the IP layer.  E.g., why aren't I using
it, when I can use other tools like SSH and
Skype easily?

(On this:  has anyone tried SSH's VPN yet?)

> what i intended to focus on was that solving this problem should be
> done at an IP endpoint level so that all services supported between
> peers (that is, user centric) could share this authenticity and
> privacy bootstrap.


That I see as a sort of VPN thesis?

> what i wanted to move away from is every application or service level
> protocol bolting an auth+privacy layer in front of their intended
> purpose, like HTTPS, STARTTLS, etc.


There is a good reason for this:  the application
knows it is there and can rely on it.  If instead
the VPN approach is taken, there is little or no
way for an application to make any statement of
security, because it doesn't know if it is there.

So...

>>All this discussion applies (I believe) as well to protecting data as it
>>does to protecting capabilities (generalized authority tokens) during
>>communication.
> 
> 
> there may be additional protection of capabilities above and beyond
> communication channel authentication and privacy.  for example, using
> public keys to facilitate inter-domain capability use instead of
> data/token/id based capabilities.


...For example, I would say that a capabilities system
that depended on an IP-level VPN approach would be
dead in the water.  A non-starter.

As the meta-requirements for capabilities include
"secure by design" it would be a bit of a bug to
rely on anything that could be turned off by a sysadm.

Which isn't to say that what you are looking at isn't
a good idea -- but it does look to be orthogonal or
independent of caps.


iang