Alliance PKI Workshop Technical Discussion/Planning Notes Progress Report

Overview Quick overview of goals and approach Duplicated technical discussion slides from December’s technical session report, and added progress reports on each

Two Overriding Goals Give Grid users easy, useful, and secure access to Grid resources Give Grid sites reasonable tools and policies to grant users this access while retaining necessary control, security, and accounting

Goals Allow users to “sign on” (authenticate) once only and then –login easily, consistently, and securely to computers; –transfer data among machines; and –submit and monitor jobs on supercomputers, even when these resources are located in different administrative domains Should also support web, LDAP, etc., etc.

Proposed Technology Approach Build on a technology base pioneered in the Globus project –Basically public key + mechanisms for mapping global to local credentials Deploy this technology and develop required supporting infrastructure –Certificate Authorities, account management Build a suite of tools that use this technology –ssh, remote job submission, ftp, etc., etc.

Proposed Approach: Policy Focus on security for interdomain operations –Assume that intradomain security is handled by existing mechanisms, which remain in place Mutual authentication for interdomain operations –Site must accept validity of authentication Allow for a program to act as a Grid user –Necessary for single sign-on when programs acquire resources dynamically

Policy Contd. Distinct global and local subject spaces; former can be mapped to the latter –Mapping can be many-to-one, one-to-one, etc. Domain responsible for access control, etc., given local subject –Hence reuse of local mechanisms Processes running on the same resource for the same user can share credentials –Contributes to scalability

Approach: Key Ideas Public key technology –Standard PK mechanisms (SSL) used to avoid plaintext passwords X.509 credentials –Standard representation of global subject name Certificate authority –Issues and signs credentials; provides strong notion of identity

Approach: Key Ideas (2) Identity map –Maps from global to local subject names –Allows sites to maintain local policies –Represents a form of access control list Delegation –A user can delegate authority to local or remote processes to act temporarily on behalf of the user

Single sign-on via “grid-id” User User Proxy GridCredential Site 1 Kerberos GRAM Process GSI Ticket Site 2 Public Key GRAM GSI Certificate Process Authenticated interprocess communication CREDENTIAL GSS-API: multiple low-level mechanisms Mutual user-resource authentication Mapping to local ids Assignment of credentials to “user proxies”

Authentication Model Authentication is done on a “user” basis –Single authentication step allows access to all grid resources No communication of plaintext passwords Most sites will use conventional account mechanisms –You must have an account on a resource to use that resource Sites may use “generic” Grid accounts –Not common, but we can deal with it

Security Infrastructure Based on public key technology –Standard X.509 certificate, same as certificates used for the Web Each user has: –a Grid user id (called a Subject Name) –a private key (like a password) –a certificate signed by a Certificate Authority (CA) An “identity map” file at each site specifies Grid-id to local id mapping

Certificate Based Authentication User has a certificate, signed by a trusted “certificate authority” (CA) –Certificate contains user’s name & public key –Globus operates a CA; should be others User’s private key is used to encode a challenge string Public key is used to decode the challenge –If you can decode it, you know the user Treat your private key carefully!! –Private key is stored in encrypted form

User Proxies Minimize exposure of user’s private key Create a temporary credential for use by our computations –We call this a user proxy certificate –Allows process to act on behalf of user –User-signed user proxy certificate stored in local file Proxy’s private key is not encrypted –Rely on file system security, certificate file must be readable only by the owner

Grid Authentication Setup Before you can run applications: –Obtain a Grid certificate and key –Set up your environment so Globus knows where to find certificates and keys –Contact sites to set up local accounts and gridmap entries –Create proxy certificate for each application run Documentation –

Overview Quick overview of goals and approach Duplicated technical discussion slides from December’s technical session report, and added progress reports on each

Clients: ssh v1 Platforms: –Unix: Mostly done by Von Welch –PC: Free low-end solution using Cygwin. Talk to Van Dyke (SecureCRT) & DataFellows. –Mac: DataFellows Unlike Alliance/NPACI ssh rollout, this does not require clients for everything. Can always fall back to normal ssh for first hop.

Clients: ssh v1 Progress Platforms: –Unix: Code reviewed 1/15, starting deployment –PC: Cygwin: Stock ssh working, gssapi.dll working, have not yet tried putting them together Van Dyke (SecureCRT): Has agreed to add GSI support in standard release; gave them code on 2/10 DataFellows: Contacted, gave them code on 2/18 –Mac: DataFellows: No progress

Clients: ftp Platforms: –Unix: Mostly done by Von, based on K5 ftp –PC: K5 ftp runs native Win32 for free version. Talk to Van Dyke (AbsoluteFTP). –Mac: Unsure, but not critical If we allow our certificates to be used in a web browser, we might be able to use the browser as a generic ftp client?

Clients: ftp Progress Platforms: –Unix: Code reviewed 1/15, starting deployment –PC: Modified K5 ftp already tested Van Dyke (AbsoluteFTP): Has agreed to add GSI support in standard releae; gave them code on 2/10 –Mac: No progress Have not yet tried loading certificate into a web browser

Clients: ssh v2 Not required by July 1 Start talk to DataFellows/SSH Inc. soon about integrating GSS-API support

Clients: ssh v2 Progress DataFellows/SSH Inc: Contacted, gave them code on 2/18

Clients: web Investigate use of PKCS#12, to allow interoperability of our certificates with Netscape and IE Need to be able to load our CA certificate into the browser Full support not required by July 1. However, we should make our certificates browser compatible by July 1, so that we don’t have to reissue them.

Clients: web Progress PKCS#12: No progress CA cert in browser: No progress

Clients: Not required for July 1. May get this for free due to web integration (Netscape Mail, Outlook) Spend a small amount of time check for compatibility before July 1

Clients: Progress None

Servers: sshd Platforms: –Unix: No problem (Von) –PC: Use Cygwin, for NT clusters –Mac: Not needed Needs sslk5 integration Plan to run on normal ssh port, since it will fall back to other versions properly

Servers: sshd Progress Platforms: –Unix: Code reviewed 1/15, starting deployment –PC: Cygwin: Have stock ssh & gssapi.dll –Mac: Not needed sslk5 integration: Working, but needs cleanup

Servers: ftpd Platforms –Unix: Von has modified K5 ftpd. May want to consider WashU ftpd –PC: Cygwin –Mac: Not needed Needs sslk5 integration Run on separate port, due to Kerberos and plaintext fallback difficulties.

Servers: ftpd Progress Platforms –Unix: Code reviewed 1/15, starting deployment –PC: No progress –Mac: Not needed sslk5 integration: Working, but needs cleanup

Servers: other Web: Apache, Netscape, IIS –Make sure we can issue server certificates Imap –Server certificates LDAP –Server certificates

Servers: other Progress Web: Apache, Netscape, IIS –No progress Imap –No progress –Small modification to gatekeeper may allow it to work like tcp_wrap, to wrap imap port LDAP –Working on setting up Netscape v4 LDAP server with SSL enabled

Authorization API All servers (sshd, ftpd, Globus gatekeeper, etc) need a generic authorization API. Not a July 1 roadblock, but would be nice to have for July 1 rollout. But if we don’t add this, we need to make some additions to the globusmap file.

Authorization API Progress GAA-API (Generic Authorization and Access Control API) –IETF draft API for authorization –Compliments the GSS-API GAA-API is to authorization, as GSS-API is to authentication Likely will not have this by July 1 (or Globus v1.1)

SSL wire compatibility We need to ensure that GSS-API is SSL wire protocol compatible. Is this in the critical path for July 1 rollout. –For grid application writers, no. –For systems tools, probably. If we change GSS- API, this will make deployment of enhanced servers (sshd, ftpd, etc) more difficult as it will require more effort to ensure backward compatibility. Getting any wire protocol change in now will make life much easier later.

SSL wire compatibility Progress We have modified GSI to (optionally) be SSL wire protocol compatible. Caveats –Some web servers require encryption, but GSI does not have this by default. We have a non- exportable version that does support encryption. –SSL limits “packets” to 16k. Some applications can benefit from larger packets. SSL packetization is optional in GSI.

Libcrack Libcrack is a simple library for performing password validity checks We’ll integrate this into globus-certreq and globus-proxy-init, to check for and warn of weak passwords

Libcrack Progress No progress Doug is questioning the utility of this...

Releases The Globus group will provide two releases: –Full release: Like now, but we better documentation for building subsets. –Authentication release: Just GSS-API and related components. Easy to build in form that is ready for ssh, ftp, etc.

Releases Progress Documentation: Efforts are underway with NCSA and NASA Authentication release: Von is just starting this. Will produce a “gsi-install” script in a stripped down version of the Globus release.

Todo Write todo list, assign responsibility, timelines Phased rollout/deployment plan map file maintainance Logging/auditing Firewalls Support!!!

Todo Progress Write todo list, assign responsibility, timelines –Have completed globus 1.1 release plans Phased rollout/deployment plan –Starting limited deployment at ANL –Need to work out deployment today map file maintainance –In 1.1, adding simple mapfile maintainance and validation commands

Todo Progress Logging/auditing –No progress Firewalls –In 1.1, have plans to allow restriction of ports to a particular range –But this probably doesn’t help ssh/ftp. Not sure what we can do to help this. Support –Need to talk about this more

Other Progress Multiple Cas –1.1 plans for allowing sites to restrict user cert signature to particular CAs –1.1 plans to support multiple user certs/CAs Entrust –Was able to convert Entrust certificate so that it could be parsed by GSI (SSLeay)

Summary No showstoppers identified Some fairly minor cleanup and port work required July 1 seems a reasonable target

Summary Progress Good progress since December Some fairly minor cleanup and port work (still) left to be done July 1 (still) seems a reasonable target