- Generic authentication frameworks
- Authentication using symmetric key cryptography
- Authentication using public key infrastructure
- Single Sign On
- Other topics
Generic authentication frameworks
PAM (Pluggable Authentication Modules) is a generic authentication infrastructure for the most common Unix like operating systems (Linux, Solaris, ...). It is used to authenticate accounts locally. There is a huge amount of different modules for various purposes existing.
pam_krb5 on Sourceforge: the best Kerberos5 pam module I've found so far. Unfortunately it has been unmaintained since 2003. Here are some of its features:
- full AFS support, including AFS token generation out of a forwarded Kerberos5 tickets (by e.g. openssh)
- renewal/refreshing of tickets/tokens with pam aware desktop lockers (xscreensaver, kdesktop_lock)
RedHat's pam_krb5 includes the following features:
- rudimentary AFS support (AFS token generation after password authentication) - no support for token generation out of forwarded K5 tickets. That's no problem for newer openssh versions, though (token generation built in).
- ticket/token refreshing with screensavers should work as well.
pam_afs by Douglas E. Engert: This module is needed to generate AFS tokens out of forwarded Kerberos5 tickets with older openssh servers.
SASL (Simple Authentication and Security Layer) is a generic authentication infrastructure for client / server connections. There are many plugins existing for various authentication techniques such as password (cleartext, md5 hash), Kerberos5 (using GSSAPI) and others.
Authentication using symmetric key cryptography
Key for encryption and decryption is the same (or easily derived from the other key). Needs a third party to establish a trust relation. In High energy Physics (HEP) Kerberos4 and Kerberos5 are used. Kerberos4 has security flaws and is largely replaced by Kerberos5.
Currently implemented in 3 major variants: MIT Kerberos, Heimdal Kerberos, Windows Kerberos
Talks at HEPiX meetings related to Kerberos
BNL (Oct 04) E.Fasanelli: INFN K5 project
Edinburgh (May 04) W.Friebel: AFS file space administration with ARC version 2
TRIUMF (Oct 03) E.Fasanelli: AFS cross cell authentication using Kerberos5
NIKHEF (May 03) W.Friebel: Kerberos5 at DESY
INFN (Apr 02) L.Giachetti: Who Let The Dog(s) In ? (update on strong authentication at FNAL)
LAL (Apr 01) D.Skow: Strong Authentication Report at FNAL
LAL (Apr 01) M.Kaletka: W2000 Kerberos Experience
See also the FNAL solution:
(Feb 05) Strong Authentication at Fermilab
Software with Kerberos Support
Usually the software mentioned below does not come with Kerberos support by default, configuration or recompilation is required in most cases.
- Webserver: IIS, Apache (so called Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) support)
- Webclients: Internet Explorer, Mozilla, Firefox
- Mailserver: Cyrus-IMAP, UW-IMAP
- Mailclients: pine, Mozilla, Thunderbird
Batchsystems: SunGridEngine, LSF
- Filesystems: AFS, NFSv4
- Protocols: LDAP, IMAP, SMTP (via SASL) Socks5
- Client/Server programs: openssh, telnet, ftp, su, arc, arcx
Other UNIX software is or could be made Kerberos5 aware by using the SASL or GSS API.
Software contributions from the HEP community
Migration from a kaserver based AFS cell to a Kerberos5 based cell is facilitated by heimdalsync (DESY)
Setup of a Kerberos 5 realm from scratch (Heimdal), fill it with AFS db data: krb5setuphd (DESY)
Patched perl module Heimdal::Kadm5 for perl 5.8 (DESY)
Enhanced Perl Module for SASL server side support Authen::SASL::Cyrus (DESY)
- Generic Client/Server solution for AFS authentication: arc/arcd by Rainer Toebbicke (CERN)
Authentication using public key infrastructure
Public key cryptography is an assymetric key method. It uses a pair of keys, called public and private key. The public key is intended for distribution, while the private key needs to be kept secret. Both keys are connected through a mathematical relation, which is highly asymmetric in terms of computational effort to derive one key from the other.
Knowing the public key it should be practically impossible to derive the private key.
In order to verify that a public key is associated with the real issuer, a Public Key Infrastructure (PKI) is installed. In most practical cases within HEP the keys used are so called X.509 Certificates. The verification of these certificates is done trough a hierarchy of trusted third parties, called Certification Authorities (CA).
The various deployed grid solutions (e.g. LCG) all use authentification with certificates
Software that is using Certificates
Talks at HEPiX meetings related to authentication using certificates
Triumf (Oct 03) A.Pace: An introduction to PKI and a few deployment hints
NIKHEF (May 03) D.Groep: Grid security and site authorization in EDG
For other talks on this subject see also "Talks at HEPiX meetings related to Single Sign On" below and
A. Pace: 2004 Cern school of computing An Introduction to Public Key Infrastructure
Single Sign On
Talks at HEPiX meetings related to Single Sign On
Roma (Apr 06) Jens Jensen: Single sign-on at RAL
SLAC (Oct 05) J.Gordon: RAL Progress in Single Sign On
Karlsruhe (May 05) E.Ormancy, A.Pace: Cross platform single-sign-on using client certificates
There is also a report on using SSO at the TFH Wildau (in german) which is using Kerberos on UNIX and a trust relationship with the realm on Windows (tested also at DESY) and a diploma thesis that describes the migration from OpenAFS kaserver authentication to Heimdal Kerberos5
One time passwords
Roma (Apr 06) R.Petkus: One-time-password integration at BNL
Synchronisation of passwords across platforms
Karlsruhe (May 05) D.Jahnke: DESY-Registry -- cross-platform user administration
BNL (Oct 04) M.Corosu: INFN TRIP Project (authenticated WLAN access)