Open sbinet opened 6 years ago
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):
auth
request,auth_more
response,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?
I guess at this point it's best to ask the xrootd
mailing list :)
(or on xrootd/issues
.)
feel free to push your WIP branch so I can have a look as well.
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?
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
?)
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
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.
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
got a PR to that Julia implementation?
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:
the main thing to be worked on on Julia side is chunking logic, and to handle in case server doesn't support Multipart GET
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
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
protocol version 4
The
xrootd
specs have a number of things to say about authentication: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, andpwd
: authenticates a user using a password-based protocolsss
: authenticates a user using a simple shared secret protocolunix
: authenticates using the Unix login name and group nameFor kerberos, we might use:
For GSI, something on top of crypto/x509+crypto/tls might be used/developed. Current specs:
blocked by https://github.com/xrootd/xrootd/issues/7573rd-party authentication:
scitokens
:protocol version 5
The
v5
specs also support aztn
protocol (based on tokens):ztn
: https://xrootd.slac.stanford.edu/doc/dev50/sec_config.htm#_Toc64492252