[cap-talk] network level designation and authorization
coderman
coderman at gmail.com
Thu Jun 8 16:49:44 EDT 2006
On 6/8/06, Stiegler, Marc D <marc.d.stiegler at hp.com> wrote:
> ...
> YURLs make it possible to do better. YURLs even make it easy to do
> better. VPNs, on the other hand, make it impossible to do better, much
> less easy.
let me simplify:
instead of httpsy[1], or captp[2] use a distinct VPN between service
endpoints. there may be only one service available at that endpoint.
(just like a single service may be available at
httpsy://*cl7h3f7jwyj3fvmw7jpnjfvf2xlcmayi@yurl.net/...)
if you want/need to bind an identifier to a particular VPN consider an
IPv6 addr derived from the secure digest of a suitable peer
identifier: (feed:7ba3:c779:e5f5:cc1a:8bc7:5fe1:ed08/16 for example,
which can be given a petname in /etc/hosts)
want to use SHA2-256 for authentication? sorry, not available in
httpsy. want to avoid a DHE-RSA-* setup cost on each session /
connection? may not be possible with either.
i am advocating simple (read: no PKI) VPNs for communication privacy
beneath plain text YURL or VatTP mechanisms, not replacing capability
security with all or nothing VPN like traditional perimeter security.
this provides advantages in terms of leverage of existing
infrastructure and flexible/efficient implementation and frees the
higher level services (YURLS or VatTP interactions) from reinventing
the wheel.
if you could structure VPN service in this manner (a big 'if', i will
admit for now), would this not be preferable to
implementation/protocol specific bindings ala httpsy or captp?
1. http://www.waterken.com/dev/YURL/httpsy/
2. http://www.erights.org/elib/distrib/captp/index.html
More information about the cap-talk
mailing list