Print

Print

Hi,

I managed to go through this and understand better.

As described at https://docs.google.com/document/d/1XjHWMHOXlDWCFtg_AnbfV7R9OICy5pq2IPwQvIwi2vY/edit#heading=h.q53z4zbfemri
in 4.9 we introduced a more correct use of the IV for cipher encryption, which is now unique for each encryption and prepended
to the buffer. So, it in normal that a buffer expected to be encrypted, as bmai in kXGC_cert, has 16 bytes (16 is length transmitted
with the choice of the cipher) prepended to the buffer content.
What is not normal is that the following buffer is not encrypted, as it seems in your case, with ‘gsi’ in bytes 17,18,19 .
This I am not able to reproduce in my setup.

Gerri



On 04 Mar 2019, at 17:25, Albert Rossi <[log in to unmask]> wrote:

Gerri, they are at the beginning of the main.  

And they are indeed different at each call.

So what is the purpose of this?  And how am I supposed to produce it?  A random 16 byte sequence?

thanks, Al

________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W) 
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023


From: ganis <[log in to unmask]>
Sent: Monday, March 4, 2019 10:23 AM
To: Bockelman, Brian
Cc: Albert Rossi; xrootd-dev; Dmitry O Litvintsev
Subject: Re: SutBucket structure for main bucket in 4.9
 
Hi,

Well, the 16 IV bytes are supposed to be copied at the beginning of the related bucket, not of the bmai serialisation.
Of course, there might be a bug.

I will try to reproduce the problem and investigate.

Gerri



On 04 Mar 2019, at 17:14, Bockelman, Brian <[log in to unmask]> wrote:

Hi Albert,

Is the 16 byte prefixed or changing on each connection?

If I look through the git log on the directory, I notice there was a 16 byte IV added to the bucket serialization in December-ish; that roughly matches your timeframe, no?  

It also looks like the IV is copied to the beginning of the serialization.

Brian

On Mar 4, 2019, at 9:57 AM, Albert Rossi <[log in to unmask]> wrote:

One last point.

If I discard the first 16 bytes of that main bucket on the incoming request, everything looks normal.

My current problem is communicating back to your client.  I am not sure what to place in the main bucket that seems to be missing.

From: Albert Rossi
Sent: Monday, March 4, 2019 9:51 AM
To: xrootd-dev
Cc: Dmitry O Litvintsev
Subject: Re: SutBucket structure for main bucket in 4.9
 
Note that I am not speaking of the whole message (your buffer), just the main bucket.

Before 4.9, our server sent and expected a main bucket structured this way:

4 bytes:  protocol
4 bytes:  step

... buckets
none bucket

in other words, it mirrors the top level structure, but is not preceded by a bucket type byte sequence.

Evidently this has now changed.

From: Albert Rossi
Sent: Monday, March 4, 2019 9:43 AM
To: xrootd-dev
Cc: Dmitry O Litvintsev
Subject: SutBucket structure for main bucket in 4.9
 
Hello all,

I have looked through the GSI documentation for this, but cannot find an answer.  

I now notice that on the cert step, our server is receiving a main bucket from the 4.9 client which does not begin with the PROTOCOL, but is prefaced by another 16 bytes.

In HEX dump:

05 EC 68 5A AB 6A 0E 2D 99 16 1F 88 49 AC BE 0E 67 73 69 00 00 00 03 E9

As you can see, the Protocol byte sequence (underscored) is no longer at the front of the bucket (67, 73, 69 = 'g', 's', 'i' ... and then 03 39 translates into the unsigned short 1001 = step).

What are those 16 extra bytes?

It seems the server needs to do something similar now as well, because when I send off the normally structured bucket to the client containing the proxy request (where PROTOCOL and STEP are the first things inside the main bucket), I see this error:  "No protocol name: do nothing", 

[arossi@otfrid Desktop]$ xrdcp49 /etc/fstab root://fndcatemp1.fnal.gov:1095//pnfs/fs/usr/test/arossi/volatile/testdata-`date | tr ' ' '.'`
190304 09:07:43 28150 sut_Buffer::XrdSutBuffer: no protocol name: do nothing  
[0B/0B][100%][==================================================][0B/s]  
Run: [FATAL] Auth failed

which suggests to me it is expecting the protocol bytes in a different position.

It would have been more convenient if these kinds of changes were described in the protocol document.

Be that as it may, could you point me in the direction of the correct solution?

Thanks again, Al

________________________________________________
Albert L. Rossi
Application Developer & Systems Analyst III
Scientific Computing Division, Data Movement Development
FCC 229A
Mail Station 369 (FCC 2W) 
Fermi National Accelerator Laboratory
Batavia, IL 60510
(630) 840-3023

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


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


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


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