xrootd: authentication

[sbinet]

protocol version 4

The xrootd specs have a number of things to say about authentication:

• kXR_auth
• kXR_authmore
• Authentication & Access Control Configuration Reference

xrdsec supports 6 authentication protocols:

• host: authenticates a user by originating host name only,
• gsi: authenticates a user using GSI protocol,
• krb5: authenticates a user using Kerberos V protocol, and
• pwd: authenticates a user using a password-based protocol
• sss: authenticates a user using a simple shared secret protocol
• unix: authenticates using the Unix login name and group name

For kerberos, we might use:

• https://github.com/jcmturner/gokrb5

For GSI, something on top of crypto/x509+crypto/tls might be used/developed.
Current specs:

• https://en.wikipedia.org/wiki/Grid_Security_Infrastructure
• http://toolkit.globus.org/ftppub/globus/papers/security.pdf
• gsi-msg-specs.pdf (retrieved from http://toolkit.globus.org/toolkit/docs/6.0/gsic/developer/index.html#gsic-protocol)
• GSI: blocked by specification of the GSI auth xrootd/xrootd#757
  • https://xrootd.slac.stanford.edu/doc/gsidocs/XRootD-GSI-Protocol-Specifications.pdf
  • XRootD-GSI-Protocol-Specifications.pdf

3rd-party authentication:

• scitokens:
  • https://github.com/xrootd/xrootd-scitokens
  • https://github.com/scitokens/scitokens-go

protocol version 5

The v5 specs also support a ztn protocol (based on tokens):

• ztn: https://xrootd.slac.stanford.edu/doc/dev50/sec_config.htm#_Toc64492252

[EgorMatirov]

According to gsi-msg-specs, p.3: the context establishment phase is nothing more than normal SSLv3 handshake messages being exchanged.
I was using RFC6101, p. 25 as a specification of SSLv3 handshake messages.
I have got TCP dump of xrootd authentication process (gist):

• the first message is a client auth request,
• the second message is a server auth_more response,
• the third message is auth request again, following with ok response (not included in the dump, since it contains only ok status).

However, the problem is that the payload of auth request doesn't look like SSLv3 ClientHello to me.

Also, the server response, which should be ServerHello following by ServerCertificate should contain ASN.1 encoded cert (you can see an example and decoding here).
But what is present looks more like the plain content of the server's crt file. The content between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- matches the certificate body.

Any thoughts?
Can you suggest me where to look for additional info?

[sbinet]

I guess at this point it's best to ask the xrootd mailing list :)
(or on xrootd/issues.)

[sbinet]

feel free to push your WIP branch so I can have a look as well.

[EgorMatirov]

I guess at this point it's best to ask the xrootd mailing list :)
(or on xrootd/issues.)

done. :)

feel free to push your WIP branch so I can have a look as well.

There is not much of the code in WIP branch yet. I tried to use tls.Client, but it works over the connection and it's a bit hard to extract only handshake from it. After doing that in a messy way, I noticed that received handshake doesn't look similar to what I have got from xrootd authentication dump and started investigation.

I suppose, that I'll start working on FUSE interface while waiting for the answer then. Is it ok?

[sbinet]

I suppose, that I'll start working on FUSE interface while waiting for the answer then. Is it ok?

SGTM.
(let's talk about this on a dedicated issue, if needed, but: do you plan to go with bazel.org or hanwen/go-fuse ?)

[Moelf]

gentle bump asking about gsi authentication, which is, I think, what's behind voms- https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuideVomsFAQ and is the most widely used one in LHC experiments?

I've heard there's a token-based auth: https://wlcg-authz-wg.github.io/wlcg-authz-docs/token-based-authorization/configuration/xrootd/ is this easier to support?

Edit: yes, it is trivial to support, it's just HTTP GET with auth in header of every request

[sbinet]

yeah, gsi is still on the TODO list.
XRootD/C++ didn't have non-GPL specs for gsi at the time go-hep/xrootd was started (w/ a really good GSoC student) and I didn't have the bandwidth to work on it when it did have those specs.

the token-based auth might be easier (as there's already a Go package to handle SciTokens), but it's still work :)

the good news is that a hackathon is coming up, so there might be some activity on this front.

[Moelf]

Thanks, I will keep an eye out for gsi, meanwhile, the token (which is HTTP) is literally trivial and I have implemented HTTP GET based stuff in UnROOT.jl directly.

Looks like they're moving to HTTP ( should have never reinvented HTTP GET in the first place), it's so much easier for me haha

[sbinet]

got a PR to that Julia implementation?

[Moelf]

yeah, the auth payload is not in yet, but it's just HTTP GET with Range: bytes=... in header, not much going on I would say, just add auth string literals to header:

• xrootd read support JuliaHEP/UnROOT.jl#150 (comment)

the main thing to be worked on on Julia side is chunking logic, and to handle in case server doesn't support Multipart GET

[sbinet]

ah, ok. http[s]://. I thought you were talking about sci-token.

$> root-ls -t https://scikit-hep.org/uproot3/examples/Zmumu.root
=== [https://scikit-hep.org/uproot3/examples/Zmumu.root] ===
version: 60804
  TTree   events    Z -> mumu events (entries=2304)
    Type  "Type/C"  TBranch
    Run   "Run/I"   TBranch
    Event "Event/I" TBranch
    E1    "E1/D"    TBranch
    px1   "px1/D"   TBranch
    py1   "py1/D"   TBranch
    pz1   "pz1/D"   TBranch
    pt1   "pt1/D"   TBranch
    eta1  "eta1/D"  TBranch
    phi1  "phi1/D"  TBranch
    Q1    "Q1/I"    TBranch
    E2    "E2/D"    TBranch
    px2   "px2/D"   TBranch
    py2   "py2/D"   TBranch
    pz2   "pz2/D"   TBranch
    pt2   "pt2/D"   TBranch
    eta2  "eta2/D"  TBranch
    phi2  "phi2/D"  TBranch
    Q2    "Q2/I"    TBranch
    M     "M/D"     TBranch

$> root-dump https://scikit-hep.org/uproot3/examples/Zmumu.root
>>> file[https://scikit-hep.org/uproot3/examples/Zmumu.root]
key[000]: events;1 "Z -> mumu events" (TTree)
[000][Type]: GT
[000][Run]: 148031
[000][Event]: 10507008
[000][E1]: 82.2018663875
[000][px1]: -41.1952876442
[000][py1]: 17.4332438965
[000][pz1]: -68.9649618071
[000][pt1]: 44.7322
[...]
[2303][Q1]: 1
[2303][E2]: 170.583132426
[2303][px2]: -68.7941360412
[2303][py2]: -26.3984004322
[2303][pz2]: -153.847603834
[2303][pt2]: 72.8781
[2303][eta2]: -1.4827
[2303][phi2]: -2.77524
[2303][Q2]: -1
[2303][M]: 96.6567276544

[Moelf]

sci-token.

AFAICT it's just a string in header,
https://github.com/jkguiang/us-cms-datalake/blob/493d78dff4d6bd572c0a795f1635a68c5849b144/exercises/unit_test/unit_test.py#L49