OK, but that means you have o identify the NAT box. That's ok but it leaves you at the mercy of the site that deploys the NAT box. I would argue that is not maintainable in any reasonable way. You want to be in control on whether you accept or reject an authentication request. Otherwise, you keep chasing people. As for what people do, that is always open to speculation. Yes, just about every KRB5 ticket I've seen allows forwarding now. That's stupid as it allows an undetected man-in the-middle attack or even stolen tokens (yes, they expire but sometimes not fast enough). As for the encryption, the whole sss interchange is encrypted. You are right in that the XRootD traffic is not encrypted and with a lot of work you could high jack the connection. My only response here is that the traffic isn't worth the effort. Anyway, whether we encode forwarding in the keyname or via an option doesn't stop people from misusing that. So, I gather that under the circumstances encoding it in the k eyname is likely preferable as it gives full backward comparability.

—
Reply to this email directly or view it on GitHub.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1