Hi Andreas,
 
There was no particular notion of securing the protocol itself after the authentication phase. It's very hard to inject packets in an open TCP stream when the protocol itself is stream based. Yes, it could be done and probably more easily on WIFI than wired. Now, that said, the system was designed to address specific HEP needs with no guarantees that it would meet the needs of others. For HEP, authentication/authorization is sufficient for even drastic operations. Plus, few if any users actually use open public WiFi for xrootd connections. Plus, virtually no one would want to target physics data for destruction, if for any reasons, is that they simply don't care -- there's better data to mess with. So, there was no specific reason to complicate the protocol to address needs that just weren't there.
 
Andy
----- Original Message -----
From: [log in to unmask] href="mailto:[log in to unmask]">Andreas-Joachim Peters
To: [log in to unmask] href="mailto:[log in to unmask]">xrootd-dev
Sent: Thursday, September 23, 2010 4:50 AM
Subject: xrootd protocol security

Hi,
I have a question regarding an extention of the security model of xrootd in general. When a socket (session) is established there is an authentication handshake on the socket. Afterwards however it seems to me that there is no security mechanism at all (against spoofing etc.) ...

Did you forsee anything to make the protocol itself 'secure' ? E.g using something like a nonce with symmetric encryption/hashing of requersts? Or would this require a drastic change on protocol level? I think it is not so much needed for the data packets, but atleast the dramatic ones like kXR_rm etc .....

Cheers Andreas.