Daniel Kahn Gillmor writes: > On 07/29/2014 07:36 AM, Tero Kivinen wrote: > > Martin Thomson writes: > > >> 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. > > I think this is a misunderstanding of what tcpcrypt offers.
I do not think there is any misunderstanding there. As I said in my text the tcpcrypt does not offer authentication credentials as it does not do authentication. It can provide the session ID, but that was covered by the item 5 in the list, not by this item. > With such a shared secret, any number of authentication hooks are > possible, including: Are possible != provided by the tcpcrypt as now. To provide the actual authentication inside the tcpcrypt would require tcpcrypt to be extended, and thats why I think the item 4 should not be there as hard requirement. With item 5 (session ID) you can do these authentication hooks as you listed below, but item 4 asked for the authentication credentials used to authentication of the other peer. > 0) transmitting a signature over the shared secret by an asymmetric key > (the public key could be embedded in a certificate). > > 1) transmitting a cryptographic digest H(session_id||PSK) for some > pre-shared key PSK to prove posession of the PSK > > So I think "no way to do authentication" is not an accurate way to > describe what tcpcrypt offers. It is accurate. Tcpcrypt does not do any of those as it is specified now. Those things can be done by the application by accessing the session id (item 5 in the list) and doing authentication in the application, but outside the tcpcrypt. Yes, tcpcrypt could be extended so that it includes the H(session_id|PSK) inside the TCP options sent in the INIT* packets but currently it does not do it, and my understanding was that it actually prefered it to be done outside the tcpcrypt and inside the application. -- [email protected] _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
