[nanomsg] Re: issue with "received" message size
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 10:03:48 -0700
>
> Those are all *application* layer questions, but having the certificate
> information available makes it possible for me to have a high level of
> confidence in the identity, which I will use in the application layer for
> this kind of policy enforcement.
>
> This is all about making life easier for application developers.
>
Now, we have the following hierarchy:
G -> A -> B
Where G is user "garrett". Now we authenticated user garrett at A, but
we can't be confident that request is made by garrett at B because A
doesn't have garrett's certificate.
That all said given that TLS is only possible for hop-by-hop security
not end-to-end. So in your case end-to-end security validation must be
done by application anyway.
You are correct. I can only authenticate my immediate peer. For many
applications, this is all that is needed. It won’t support richer device
patterns, although one can imagine building configurations where an edge router
on the network receives requests, performs the authentication, and then ships
them off to an internal service following the device model, but extending that
to add information about the authenticated user. Its not possible to do this
with device off the shelf, but not hard to build either, and its a
well-understood architecture.
However, I’m also thinking of some “tunneling” approaches where SP is used as a
transport to fabricate a stream (making full use of rich hop-by-hop routing in
SP), and on top of that virtual stream, we run TLS, and inside that TLS tunnel
we can get end-to-end security. This is sort of like an SP-specific VPN.
Basically, SP becomes an application layer protocol on top of itself with some
crypto sandwiched in between. :-)
- Garrett
Other related posts:
