Re: [HTCondor-users] Documentation about tokens workflows

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

On 5/5/2023 11:55 AM, Marco Mambelli via HTCondor-users wrote:

> Greetings, I'm looking for detailed documentation about the token authentication workflows (IDTOKENS, SciTokens ...).
>
> Specifically I read the authentication section in the manual (https://htcondor.readthedocs.io/en/latest/admin-manual/security.html#token-authentication and more)
> and I have some questions especially about when SSL authentication and X509 certificates are required.
>
> 1. Seems that once the client has an IDTOKEN the SSL authentication and client or server certificates are not needed. Is this correct?
>     
    
    Correct.
    
> How is authentication (a confidential channel) bootstrapped?
>     
    
    So the client possess an IDTOKEN, which follows the JSON Web Token
    (JWT) standard and consists of three sections: the header, the
    payload, and and a digital signature across the header+payload
    created with a signing key on the server (in
    /etc/condor/passwords.d).   To bootstrap: So first thing, on a fresh
    insecure TCP socket, the client sends just the header+payload
    sections from the IDTOKEN over the wire over to the server.  The
    server receives this, and then signs it using the signing key
    already in its possession to re-create the digital signature.  Now
    both the client and the server posses the digital signature for the
    token, even though it was never passed over the network.  This
    digital signature is used as a shared secret to initiate a secure
    communication channel via the AKEP2 protocol.
    
> 2. Is the above the same also for daemon-to-daemon connections?
> E.g. a schedd or startd talking to a collector where I'm assuming the collector to be the IDTOKEN issuer and the only server w/ the password to issue/decode tokens.
>     
    
    Yes.  Every daemon that initiates a connection to another daemon is
    considered to be a client, so the above does not change.
    
> 3. In the daemon to daemon communication section (https://htcondor.readthedocs.io/en/latest/admin-manual/security.html#daemon-to-daemon-connections-daemon-authentication) I read about limitations of some features if the server does not have the password to verify the tokens. I have to verify with the latest HTCSS, I did not remember these.
> E.g. Can a schedd do a condor_ssh_to_job also without having the POOL password (only the collector has the password to sign and verify the idtokens)?
>     
    
    With current versions of HTCSS, the limitations you reference above
    are gone.  I will make a ticket to update this part of the
    documentation.   
    
    Specifically, in the case of condor_ssh_to_job and condor_tail, the
    authentication between schedd + startd does not need tokens / POOL
    passwords on the schedd/startd because it will automatically use
    "match password authentication" --- essentially the startd will
    randomly create a secret key, pass it securely to the central
    manager (perhaps via IDTOKEN), and then the central manager passes
    it securely to the schedd.  Info on match password authentication
    can be found in the Manual at config knob
    "SEC_ENABLE_MATCH_PASSWORD_AUTHENTICATION" (True by default), and
    also in the research paper "Flexible Session Management in a
    Distributed Environment" available at 
    https://chtc.cs.wisc.edu/doc/flexible_sessions.pdf  
    
    Another area where there used to be a limitation is administrator
    tools that wanted to connect directly to daemons, such as
    condor_drain or condor_off, via IDTOKENS and these daemons (e.g.
    startds) did not posses a signing key .  However, in HTCSS v9.10 +,
    this limitation was removed - see documentation for knob
    SEC_ENABLE_REMOTE_ADMINISTRATION (True by default).  
    
> 4. SSL and at least a server certificate are needed when a token is retrieved (condor_token_request, condor_token_fetch). 
> Is the retrieval (communication channel)  secure also without a client certificate?  
> I'm not assuming a secure/private network and I know that the requestor is unauthenticated, I'm asking form the client point of view if it can use that token to start an encrypted communication with the server.
>     
    
    For IDTOKENS, SSL is not "required" --- in fact, one of the nice
    things about IDTOKENS is they are self-contained and do not require
    SSL/host certs.    Folks are free to distribute tokens however they
    want (scp, puppet, ssh cut-n-paste, ...).  In the case of
    condor_token_fetch, which asks the server to mint an IDTOKEN with
    the same identity that the client authenticated as, it is common for
    FS (filesystem) authentication to be used when an end-user can login
    to the AP machine and thus the schedd is local - no SSL required.  
    If you are retrieving an IDTOKENS from a remote server, then you
    need some form of network-happy authentication (i.e. not FS).  Like
    the usual SSL used by your web browser, only server certs are
    necessary for the client to both trust that the server is who it
    wants to talk to and to create an encrypted communications
    channel.   
    
> 5. With SciTokens or WLCG IAM I think the server must have a valid host/server certificate also if the client has already the token. Is this because it relies on an external verification system?
>     
    
    IIRC, this is correct, and thus the  SciTokens authentication method
    in HTCSS uses/requires SSL as the transport layer (unlike IDTOKENS,
    which does not require SSL) . 
    
> Does the client need a trusted certificate as well? Only when requesting a token?
>     
    
    With SciTokens, not sure, probably depends on the issuer.  
> Feel free to point me to documents (white papers, articles, ...  ) for some of the answers.
> Or PM me if the information is confidential.
>     
    
    Nothing should be confidential - after all, HTCSS is fully open
    source :).  Security is only ever supposed to depend on the secrecy
    of the keys, not the algorithm(s)  
    
    Past HTCondor workshops are a good source of detailed/in-depth info;
    see https://htcondor.org/past_condor_weeks.html  
    Specifically HTCondor Week 2022 from last year had tutorials on both
    IDTOKENS and SciTokens; both slides and complete YouTube recordings
    of the presentations are online.  Look for "IDTOKEN" and "SciToken"
    keywords in the titles of the presentations here:
       https://agenda.hep.wisc.edu/event/1733/timetable/#all.detailed
    
    Hope the above helps,
    regards,
    Todd