Glenn Horton wrote:
>
> Has anyone ever considered providing a GSS-API interface into OpenSSL?
Yes, the Globus GSI is a GSSAPI implementation using SSL.
See http://www.globus.org/security/v1.1/
This has been in operation for over two years, originally using SSLeay, and now
OpenSSL.
It has been run at 100 sites, on laptops to supercomputers, on 5 continents. You can
see
it in action at Super Computing SC2000 next month. http://www.sc2000.org/
GSSAPI Delegation is also implemented. This is done using a "proxy" certificate. After
the SSL handshake has done the authentication, the server creates a key pair, and a
request which is sent to the client, signed and returned to the server as a proxy
certificate.
The verify_callback has been modified to accept these proxy certificates as part
of certificate chains.
The GSI can also use PKCS#11 so you can have your certificate and key on a smartcard
too.
>
> I realize that such an undertaking would be non-trivial. However, I'll try
>to justify
> my question in case anyone is interested.
>
> I've spent a considerable amount of time trying to determine if I can make
>OpenSSL
> work for my applications. I've come to the conclusion that, in its present form, I
>am probably not
> going to be able to use OpenSSL.
>
> Some of the difficulties that I'm having revolve around the fact that the
>socket I/O code is
> integrated into the protocol code. Our applications are designed around a
>GSSAPI/SSPI model
> where the application does the I/O and gets buffers from the protocol provider and
>sends buffers
> to the protocol provider.
We got around this by having the SSL BIOs point to memory BIOs, then when the SSL code
waits
for more data, we take up all the output data, and return this as a GSSAPI token. On
the other
side, this is then put into the read BIO, and SSL is called again.
> Two specific situations where I have a problem with OpenSSL is that I had
> planned to tunnel SSL inside of another, application specific, protocol. I haven't
>been able to
> determine how to do this.
We have mods to SSH and FTP to use GSSAPI for authentication. The GSSAPI tokens which
contain
the SSL handshake data are tunneled via SSH. So this should not be a problem.
> Also, our servers can handle large numbers of clients concurrently.
> Because of this feature, I don't like the fact that it appears that a SSL call could
>bock my server
> unless I make the server multithreaded. The fact that the OpenSSL code contains so
>much static
> data make me wonder if OpenSSL is thread safe. Does anyone have an opinion on that?
>
> Thanks, in advance, if you have kept reading long enough to get this far.
>Any response,
> whether it be questions, comments, suggestions, criticism etc., will be most
>appreciated.
The one issue which still needs to be addressed is the session renegotiation.
Currently GSSAPI
has no way to enter back into the gss_init_sec_context/gss_accept_sec_context loops if
one side wishes to renegotiate. We are looking at extensions to GSSAPI to support this,
and will be bring them to the IETF.
If you have any questions, drop me a note.
>
> Thanks!
>
> Glenn Horton SAS Institute
> 919-531-6640 R4306 SAS Campus Dr.
> [EMAIL PROTECTED] Cary, N.C. 27513
>
> SAS... The Power to Know
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
