 |
 |
Hmmm, I personally don't like the first two solutions. I was imagining a trusted host directive which allows a server to trust tickets even if there is no ip match in the handshake and one specifies the NAT gateway IP to be trusted. 3 is from the deployment point of view the simplest option but the result is, that everybody would probably this type anyway not to exclude certain sites. Nevertheless to rely on an IP address of a connection is not secure, it just makes it a little bit more challenging for an attacker ... and all the traffic is not encrypted anyway ... Cheers Andreas. On Wed, Oct 15, 2014 at 6:03 AM, Andrew Hanushevsky < [log in to unmask]> wrote: > OK, after due consideration the only way to solve this correctly is to > allow an sss token to be forward-able. For security reasons, this needs to > be done on a key-by-key basis. The idea is that if a site is behind a NAT > box then you have to give that site a keytab with keys that generate > forward-able tokens (something akin to KRB5). The way it would be done is > specifying the "-f" option (new) on xrdsssadmin when you add a key. Now, > the problem is how to provide backward comparability. There are three ways > to providing some semblance of compatability but each has side-effects. > These are > > Method 1: When xrdsssadmin writes out the key file, it will write out > record using "format 0" if no special flags exist and "format 1" if a > special flag exists (e.g. -f). Unfortunately, only R4.1 xrdsssadmin knows > how to process format 0 and format 1 records. R 4.0 and below does not and > they will refuse to read he keytab if it contains any format 1 records. So, > you can only distribute old-style keytabs to old sites. This is very > annoying. > > Method 2: Always write out the records using format 0. R 4.1 xrdsssadmin > will pick up the flag values and R4 or below will simply ignore them. All > good and well. However, if you ever use an R4 or below xrdsssadmin command > to add a key to an existing keytab all of the flag values will be reset to > 0 because the old ones never processed them to begin with. Perhaps less > annoying but potentially very harmful (or at least confusing when it > happens). > > Method 3: Ditch the -f option and make forwarding a quality of the > keyname. For instance, if the key name starts with '@' then it is deemed > forward-able. So, everything is backward compatible except to the extent > that people are sensitive to key name formats (and who knows where that > might occur). Also, it's kind of icky. > > So, please pick your poison as we have a working prototype and just need > to settle this issue. > > Andy > > — > Reply to this email directly or view it on GitHub > <https://github.com/xrootd/xrootd/issues/147#issuecomment-59155069>. > --- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/147#issuecomment-59169691 ######################################################################## 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