[seek-dev] FW: your comment(s) for GSI and CA in SEEK project

Bing Zhu bzhu at sdsc.edu
Thu Aug 28 16:23:00 PDT 2003


Matt,

Below are some comments and document(s) regarding setting up CAs from Bill
Link,
who is in charge of security, especially GSI at SDSC , and is also a
SDSC GSI person in Teragrid(TG) project.

I especially want to know how the certificate issued by a different CA can
be
used in another place since we already have CA at SDSC and SRB have been
using GSI in many places.

BTW, we have a group of people led by Arun in SRB are implementing XQuery
for SRB. Some simple queries have been implemented and we are still working
on it.
I just mentioned it in my mail  before and this activity does not conflict
with our
decision to implement the QueryInterface for EcoGrid.

And also I think it is a good idea to adopt the OGSA as a way to build
EcoGrid.
I would suggest that this work be our next focus. OGSA-DAI is too specific
for databases and therefore is not fit for our Ecogrid. But we can build
OGSA services
on the top of Metacat, SRB, etc.

SRB has already implemented GSI authentication by calling GSI APIs. Metacat
can
take the advantage of OGSA and move GSI to the OGSA service layer.

At SRB, we just started to design and implement some OGSA services on top of
SRB.
If we identify this as our major work for both SRB, Metacat, etc, I will
immediately join the SRB's
OGSA effort.

Sincerely,
Bing




-----Original Message-----
From: Bill Link [mailto:bill at sdsc.edu]
Sent: Thursday, August 28, 2003 3:39 PM
To: Bing Zhu
Cc: Bill Link
Subject: Re: you comment(s) is appreciated for GSI and CA in SEEK project


On Thu, 28 Aug 2003, Bing Zhu wrote:

Bing,

    The Teragrid system at SDSC currently recognizes nine CA's, two are
SDSC's.  I am not sure what process Keith went through to evaluate the
CAs.  If one was to be strict about accepting certificates issued by
outside CAs one would read their Certificate Policy document to see if
the CA is being run in an acceptable manner.  If the certificates were
to be used in a high security environment then additional checks might
done.  The SDSC certificate policy and practice document can be found
at http://www.npaci.edu/CA/SDSC_CP.
    It is difficult for me to evaluate the plans for setting up a CA
system described in the e-mail because, I am not familiar with the
EcoGrid operating environment.
    I've attached to this e-mail the introductory portion of a paper
I've written which describes how the SDSC CA system operates.  It is
only a page long but, it will give anyone who reads it some idea of the
design and operation of the system.  You can pass this on to the EcoGrid
folks and, if they are interested, I can supply them with more information
and with the CA system source code.

Bill







> Bill,
>
> The SEEK project is planning to adopt the GSI for authentication within
our
> SEEK's EcoGrid.
>
> Since you have been working in the Teragrid projects to set up policies,
> CAs, etc,
> to use GSI among Teragrid collaborators, would you read the following mail
> from Matt Jones and send us some comments based on the TG experience(s),
> especially in the issue for a site to accept certificates issued by
> different CAs?
>
> Your comment(s) is/are definitely appreciated.
>
> Bing
>
>
>
>
>
> -----Original Message-----
> From: seek-dev-admin at ecoinformatics.org
> [mailto:seek-dev-admin at ecoinformatics.org]On Behalf Of Matt Jones
> Sent: Sunday, August 24, 2003 4:39 PM
> To: seek-dev
> Subject: [seek-dev] EcoGrid: GSI and certificate authority (CA)
>
>
> Raja, Dave, Bing, Jing, and other EcoGrid enthusiasts,
>
> If the EcoGrid is to use OGSA as its infrastructure, it makes sense to
> use the Grid Security Infrastructure (GSI) for our authentication
> mechanism.  I have been exploring this with the GT3.0.1 install on
> dev.nceas.ucsb.edu, and earlier installs.  It seems like a good decision
> to me, but would engender some changes (minor?) in our current approach
> to authentication in the ecogrid query interface.
>
> To use the GSI, we need a Certificate Authority that 1) we can trust, 2)
> is easy to manage, and 3) is accessbile (ie, SEEK admins can create new
> accounts easily without outside intervention).  I have installed and
> experimented with the SimpleCA certificate authority, and it seems
> pretty straightforward to administer it and sign certificates.  If we
> were to go this route, then we would need to:
>    1) Establish a DN system for naming hosts and users throughout EcoGrid
>    2) Set up and easy-to-use admin interface for the CA
>    3) Write a detailed signing and authentication policy, and review the
> trust model that is implicit in it for flaws
>    4) Create a system to store public keys for a large number of users
> and hosts (> 5000)
>
> Here's a proposed DN format for the CA, hosts, and users (comments
> appreciated)...
> For the CA:  o=EcoGrid,cn=EcoGrid Certificate Authority
>   For hosts:  o=EcoGrid,dc=nceas.ucsb.edu
>   For users:  o=EcoGrid,dc=nceas.ucsb.edu,cn=Matthew Jones
>
> Our current KNB approach to using a distributed LDAP server works well
> because it leverages already existing directory services, and so we have
> over 5000 accounts in that system.  Generating a parallel system for
> certificates seems crazy, so I've been contemplating trying to store
> certificates in the LDAP system that we already have running. Of course,
> the KNB LDAP server uses different DN conventions
> (dc=ecoinformatics,dc=org,o=NCEAS,uid=jones), and so we would have to
> resolve those.  I'm fairly certain that could be done through simple
> referrals in the tree.  For stability, I suggest that we decide on this
> format early, formalize it, and stick with it (generating new certs for
> everybody would be a monumental pain).
>
> We may want to explore the CAS (Community Authentication Service?) that
> has been proposed as an extension to GSI because of its mechanism for
> allowing management of trust relationships in terms of groups of users.
>   Are there any other existing systems that would make sense to explore?
> NPACI's CA?   Other existing CA's?  MyProxy?
>
> I would like to get a formal proposal worked out before the October
> All-hands meeting, so please provide feedback ASAP.  This is a
> fundamental architectural decision for EcoGrid, and I'd like as many
> people to consider it as possible.  So I suggest we follow something
> similar to the following steps:
>
> 1) Draft security policy and architecture
> 2) Build security prototype
> 3) Request public review of approach from ecology domain and others
>      (e.g., anyone considering hosting an EcoGrid service)
> 4) Revise policy from feedback
> 5) Implement and test
> 6) Run community-wide vote on acceptance of approach for interested
parties
>
> Thanks in advance for your thoughts,
> Matt
>
>
> _______________________________________________
> seek-dev mailing list
> seek-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>

--

=====================================================================

                         William J. Link
                   Security/Systems Programmer
              Distributed Computing Development Group
                  San Diego Supercomputer Center

University of California, San Diego             bill at sdsc.edu
NPACI/SDSC, MC 0505                             Phone: (858) 822-0851
9500 Gilman Drive                               FAX:   (858) 534-5077
La Jolla, CA 92093-0505

=====================================================================
-------------- next part --------------

         Cacl, a CA System with Automated User Authentication

       
                         William J. Link
                 San Diego Supercomputer Center
               University of California, San Diego
                           July, 2003


Introduction and Summary of Operation:

    Cacl is an OpenSSL based CA (Certificate Authority) system which was
developed at the San Diego Supercomputer Center to speed up and simplify the 
issuance and use of digital certificates, both for users and for the CA 
manager.  It accomplishes this, in part, by automatically authenticating the
identity of a certificate requester, thus reducing the administrative burden 
of CA management and essentially eliminating delays for the users.  In 
addition, cacl creates for the user the certificate environment needed by
Globus software, which helps simplify the task of getting started in grid 
computing.  The system was conceived of, designed, and developed at SDSC by 
the author and Wayne Schroeder.  It was put into production use in 2000 and 
has been running at SDSC since that time.  The cacl CA system has replaced a 
Netscape Certificate Management System for use in issuing all client and 
server certificates at SDSC.
    The cacl CA system is based on a client/server model.  The client 
program, called cacl (Certificate Authority CLient), is run by users 
logged into machines within the SDSC domain, to request client certificates.
When a user runs the cacl program to request a certificate he is prompted
for the password used to login to the account from which cacl is being 
run.  Next the user is prompted for a private key encryption password.
Additional information which will be included in the certificate request
is extracted from the user account's /etc/passwd entry, these items are:
user name and user login name.  The cacl program constructs a PKCS#10
certificate request based on a modified OpenSSL configuration file
into which user information has been added.
    After cacl constructs a certificate request it then encrypts the 
request using the certificate authority's certificate.  This is done in 
order to protect the certificate request file which contains the user's 
login password in the challenge password field of the request.  Cacl then 
opens a socket connection to the cacl system's CA daemon, which is running 
on a machine dedicated to CA functions, and sends the request to the CA.  
The CA daemon decrypts the request using its' private key and, after 
determining from which machine within the SDSC domain the request originated,
begins the process of authenticating the user.
    At SDSC most of the machines from which cacl can be run have their
account information recorded in a single file which is managed by an
account management system.  The information found in the passwd
file maintained by this system is what would normally be found in 
Unix /etc/passwd and /etc/shadow files.  The CA daemon is able to 
authenticate the user requesting a certificate by checking this passwd
file.  After matching the login name and user name from the GECOS field
with the information in the certificate request the password is checked.
The salt from the user's encrypted password in the passwd file together 
with the password provided in the certificate request is run through crypt 
to encrypt the password supplied in the certificate request. The newly 
encrypted password is then matched against the user account's encrypted 
password in the account management system's passwd file for the machine 
from which the certificate request originated.  This process authenticates 
the certificate requester to the same level of certainty that ordinary 
account login provides.  This is appropriate given that the certificate
issued by the CA will provide the user with a  method of authentication 
in addition to ordinary password authentication but not confer any 
authorization above that available through account login.
    After the CA daemon has evaluated the certificate request it will 
either issue a certificate and send it back to the cacl client program 
through the socket connection or send a rejection notice back to cacl. 
In either case it usually takes only ten to twenty seconds to establish
the socket connection, send the request, evaluate the request, and get
a certificate or rejection notice back to the user.
    Another component of the CA system is the caad (CA ADministrator) 
program which an administrator can use to revoke certificates and create
server certificates.  This program is available only to the administrators
of the CA system and must be run on the machine which provides the CA 
service.


More information about the Seek-dev mailing list