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 -----
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.