Tero Kivinen wrote this message on Tue, Jul 29, 2014 at 14:36 +0300:
> > 4. Able to access peer authentication credentials (often in
> > combination with 3)
>
> This one is quite hard in practice, and will depend a lot about the
> actual protocol we select. In the tcpcrypt there is no way to do
> authentication, so there cannot be any authenticated credentials
> there. In TLS there is, but getting that information to the
> application is quite complex, and the formats are different
> (certificates, identities, user names etc).
>
> So I think we should move this to as lowest priority item.
I agree... This is suppose to be opportunistic encryption, and
requiring auth credentials would make this protocol as heavy weight
as TLS.. If we add this, then each connection will have to be able
to set their own credentials, and we can't doing things like batch
signing that was proposed w/ tcpcrypt...
You shouldn't require binding to the peer's credentials as if the
machine reboots, the peer might get new credentials... And if we
don't change them (depending upon protocol) durning runtime, you might
end up w/ the problem that plagues apache/TLS in that if you get access
to an apache process and extract the master key, then all the sessions
can be decrypted because of session cookies that are transmitted to
facilitate fast session establishment for TLS...
So, this API has only maginal uses that I see...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
