Password?

1. CLASP Project Update C5 Meeting, 16 June 2000 Denise Heagerty, IT/IS Password? Password? Password? Password? Password? Password? Password?

2. Outline • CLASP purpose and phase 1 Goals • Service survey results • Kerberos feasibility results • Integration with GRID applications • Smart cards • Security and Off-site considerations • Common Access Rights • Kerberos v5 Advantages Summary • Next Steps

3. Project CLASP Purpose For users both on and off the CERN site: • Investigate and propose a plan for implementing a common authentication mechanism for use by CERN services. • Investigate and propose a platform independent mechanism to provide controlled access to objects (e.g. systems, files, web pages) for authenticated users.

4. Phase 1 Goals • Document the current login/password mechanisms used on IT and AS services • Assess the feasibility of Kerberos v5 and/or other technology as a common authentication mechanism for the planned Windows 2000 & Linux 2000 environments • Investigate possibilities for platform independent access control • Propose next steps, including personnel and budget estimates

5. Service Survey Results • Service Survey at http://cern.ch/proj-clasp • Survey lists more than 30 different user services in IT, AS, EST, SL and ST Division • using more than 12 different passwords • Most IT services use a common loginid centrally managed in CCDB • AS Division integration is in progress • There is some password harmonisation: AFS, AIS, CADIM, MAIL, NICE • The explosion of different loginid/password pairs is mainly driven by web authors

6. Kerberos v5 Availablility • Kerberos v5 is available in both W2000 and Linux RH v6.2 • KDC, libraries, some applications • AFS (Kerberos v4) requires a UNIX KDC • MIT KDC + AFS extensions exist in public domain • W2000 requires a W2000 KDC • Microsoft Kerberos includes security data • A complete solution requires separate KDCs with synchronised passwords • documented by Cybersafe and Microsoft • uses cross-realm authentication between the UNIX and W2000 KDCs

7. Kerberos Realms Common Database W2000 Realm Linux Realm KDC1 KDC2 W2000 clients and servers UNIX clients and servers

8. Applications Survey • Single Sign On requires Kerberos interfaces in both client and server applications • Defined by RFC2078: GSS-API (W2000 uses SSPI) • Kerberized initial login is not enough for SSO • A CERN applications survey is in progress • covers software in use today and Kerberos availability • Availability of Kerberized applications is limited, but popularity is growing • Influenced by changes in US encryption exportation laws and adoption of Kerberos by Microsoft?

9. Kerberized applications • Mail • IMAP server (U of Washington) - Yes! • Outlook and Pine - Yes! • Netscape - ? • Interactive Commands • telnet, ftp, rcp, rlogin: UNIX - Yes! / W2000 - ? • X, Xlock: Exceed - No / Others - ? • File Access • AFS - Yes (via Kerberos v4 extension on UNIX KDC) • Microsoft NTFS: W2000 - Yes! • Directory access • LDAP and Active Directory - Yes!

10. Kerberized Web • A web server accesses web pages onbehalf of the client • For protected pages, web server proposes authentication schemes to the client • No general solution for Kerberos v5 • A Kerberos v5 solution is documented for Internet Explorer based on a server plug-in • documented in a White Paper by Cybersafe • web server can be UNIX (GSS-API) • plug-in uses client forwarded TGT to act on its behalf • needs further investigation

11. Integrating GRID Applications • Globus GRID security is based on PKI • PKI = Public Key Infrastructure • Public Key kept in an X.509 certificate • PKI does not provide Single Sign On • private key is protected by a password/PIN code • Globus have implemented User Proxy Certificates to achieve Single Sign On • your proxy private key is protected by the file system • proxy certificates work in the Globus environment • Globus provide SSO between Kerberos v5 and Proxy Certificates • can generate a proxy certificate from a Kerberos TGT

12. Smart Cards • Can store a user certificate and private key • protected by a PIN code, normally requested each time the certificate is used • Could be combined with new CERN physical access cards (at extra cost for the chip and writer) • UBS smart card could be used for CERN authentication • Globus works with Netscape on a PC (PKCS#11) • Card readers connect to serial or USB ports • Integrates with Kerberos v5 and Globus SSO • Early technology - compatibility problems • Not a general solution for off-site access • requires card readers at all remote sites and systems

13. Security Considerations • Security of Single Sign On depends heavily on protection of the initial password • A kerberized initial login on a local W2000 or Linux system will not expose the user password on the network • A kerberized initial login across the network can expose a password • Unencrypted sessions: e.g. X Windows, telnet, … • Network logins require additional security mechanisms to avoid exposing valid passwords - particularly off-site access

14. Off Site Access • We need to review off-site access to CERN • Password sniffing is a serious and growing problem • FNAL are adopting One Time Passwords using crypto cards combined with Kerberos v5 and SSO • Other sites enforce ssh, but this only reduces network sniffing - user can still expose a password • Solutions for portables should be possible • can be configured as if at CERN • Kerberos v5 (cross-realm) with trusted sites • authenticate at remote site - no password at CERN • Need a general solution for other sites

15. Common Access Rights • Key/Initial applications: • distribution lists • web page protection • file protections • Concept of “e-groups” looks useful • electronic grouping of people/accounts • defined centrally and made available to applications • LDAP / Active Directory play a key role • work is in progress

16. Kerberos v5 Advantages Summary • Common authentication technology across W2000 and UNIX platforms • can focus expertise on a single protocol • A basis for cross-platform Single Sign On • Requires kerberized applications • Allows authentication agreements with trusted remote sites • cross-realm tests discussed with FNAL • Integrates with GRID Single Sign On • Proxy certificates generated from Kerberos TGTs • Integrates with PKI • PKINIT: from a certificate you can obtain a TGT

17. Conclusion • Kerberos v5 provides a good basis for common authentication and Single Sign On • infrastructure available in W2000 and Linux RH v6.2 • standard application interfaces (RFC 2078, MS-SSPI) • Some PKI (Public Key Infrastructure) is required for GRID applications • Can be integrated with Kerberos v5 Single Sign On • Enhanced security is essential • to overcome the vulnerability of the initial sign on • We need to control the explosion of web loginid/password pairs • may need to consider non-Kerberos solutions

18. Next Steps: until Sep 2000 • Continue testing: • Kerberised mail, web, oracle applications • cross-realm authentication • GRID authentication and Kerberos integration • Collect feedback from the service providers • cost/benefit analysis • availability of resources for detailed planning • Prepare a proposal for CLASP Phase 2 • Present proposal to an open C5 meeting before next FOCUS meeting (12 Oct 2000)

19. http://cern.ch/proj-clasp CLASP studies have been made in collaboration with many colleagues both inside and outside IT Division - Thanks! Password? Password? Password? Password? Password? Password? Password?