Don't know what the grandparent meant by GSSAPI, that is just an API for various underlying auth methods. But what people usually use together with GSSAPI is Kerberos.
Kerberos can be very secure, much more so than CA-based or generally asymmetric crypto based approaches. Kerberos (if you ignore some extensions) uses symmetric cryptography, so it is less vulnerable to quantum computers. Use AES256 and you are fine, a quantum attacker can at the most degrade this to a 128bit level (according to current theories). Also, no weak RSA exponents, elliptic curve points at zero, variable-time implementations or other common pitfalls of asymmetric crypto. The trusted third party ("KDC" in Kerberos) distributes keys ("tickets") for pairs of user and service-on-server, so mutual authentication is always assured, not like in ssh or https where you can just ignore that pesky certificate or hostkey error. Keys are short-lived (hours to weeks usually), but there are builtin mechanisms for autorenew if desired. Each side of a key can also be bound to a host identity, so stealing tickets (like cookies in HTTP) can be made harder (but not impossible). The KDC can (theoretically, rarely implemented) also enforce authorisation by preventing users from obtaining tickets for services they are not authorized to use (the original idea of Kerberos was to just use it for authentication, the authorisation step is done by the service after authentication has been established).
Single-Sign-On with all the usual protocols is included automatically, you log in to your workstation and get a ticket-granting-ticket that can then be used to transparently get all the subsequent tickets for services you are using. The hardest one to implement is actually HTTP, because browsers suck and just implement the bare minimum.
However, the whole of Kerberos implementations is ancient, 1990s era software, packed with extensions upon extensions. You don't really want to expose a KDC to the open internet nowadays. The whole thing needs a redesign and rewrite in something safer than 1990s era C.
Oh, and there are mechanisms for federation like trust relationsships between realms and KDCs, but nobody uses those beyond merging internal corporate networks.
Doesn’t this require the server to consult the IDP on every log in, though, to make sure the id token is valid? One of the staples of ssh from a UX standpoint is that it’s peer to peer.
EthanHeilman|11 months ago
thyristan|11 months ago
Kerberos can be very secure, much more so than CA-based or generally asymmetric crypto based approaches. Kerberos (if you ignore some extensions) uses symmetric cryptography, so it is less vulnerable to quantum computers. Use AES256 and you are fine, a quantum attacker can at the most degrade this to a 128bit level (according to current theories). Also, no weak RSA exponents, elliptic curve points at zero, variable-time implementations or other common pitfalls of asymmetric crypto. The trusted third party ("KDC" in Kerberos) distributes keys ("tickets") for pairs of user and service-on-server, so mutual authentication is always assured, not like in ssh or https where you can just ignore that pesky certificate or hostkey error. Keys are short-lived (hours to weeks usually), but there are builtin mechanisms for autorenew if desired. Each side of a key can also be bound to a host identity, so stealing tickets (like cookies in HTTP) can be made harder (but not impossible). The KDC can (theoretically, rarely implemented) also enforce authorisation by preventing users from obtaining tickets for services they are not authorized to use (the original idea of Kerberos was to just use it for authentication, the authorisation step is done by the service after authentication has been established).
Single-Sign-On with all the usual protocols is included automatically, you log in to your workstation and get a ticket-granting-ticket that can then be used to transparently get all the subsequent tickets for services you are using. The hardest one to implement is actually HTTP, because browsers suck and just implement the bare minimum.
However, the whole of Kerberos implementations is ancient, 1990s era software, packed with extensions upon extensions. You don't really want to expose a KDC to the open internet nowadays. The whole thing needs a redesign and rewrite in something safer than 1990s era C.
Oh, and there are mechanisms for federation like trust relationsships between realms and KDCs, but nobody uses those beyond merging internal corporate networks.
dcow|11 months ago
lxgr|11 months ago