Subject: Re: Using GSSAPI with specific providers

From: Michael B Allen <[email-masked]>
Date: Fri, 8 Dec 2006 16:09:14 -0500

I'm also sending this to kitten (the GSSAPI working group mailing list).

On Fri, 8 Dec 2006 09:48:50 -0800
"Henry B. Hotz" <[email-masked]> wrote:

> If you google "altman sspi gssapi sample" you can find references to  
> example code for how to use SSPI and GSSAPI in a compatible way.   
> SPNEGO is a supported mechanism for most current GSSAPI  
> implementations (including the ones in the MIT and Heimdal  
> implementations).
> 
> I'm not sure how much of a subset the current GSSAPI implementations  
> are.  The one area I know to worry about is the ability to auto- 
> negotiate from GSSAPI/SPNEGO/krb5 to GSSAPI/SPNEGO/NTLMv2 if needed.

GSSAPI only deals with authentication. As you point out NTLMSSP is
not supported by most (any?) GSSAPI implementations but that's not the
problem.  GSSAPI could support NTLMSSP using the current model just fine
(although I don't know about the Schannel provider). The problem has
more to do with how SSPI integrates with host credential management.
Because everything goes through gss_cred_id_t you have a bunch of issues
regarding how to get credentials for use with GSSAPI and with how to
get credentials from GSSAPI for use with non-GSSAPI software.

For example, how do you get a gss_cred_id_t from a username and
password? Not defined. How does a service get the delegated credential
in a form that can be used with Kerberos aware software like libcurl or
the pgsql driver? Not defined [1].

Also SSPI splits out a lot of functionality like encryption and signing
whereas GSSAPI tries to parameterize that with poorly defined concepts
like gss_qop_t.

For the OP to implement SSPI in WINE GSSAPI alone will not even come
close.

Mike

[1] It has been suggested that a GSSAPI function be added to export a
Kerberos 5 credential cache file. The KRB5CCNAME environment variable and
credential cache file mechanism is not suitable for acceptors (e.g. HTTP
daemon cannot adequately protect ccache files). The creds should really
be hosted in memory controlled by the kernel. Then GSSAPI could add a
"save cred" flag that specifies that delegated credentials should be saved
there in a mechanism specific way that would also be accessible to other
non-GSSAPI aware code.

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 08 Dec 2006 15:46:59 -0600

> get credentials from GSSAPI for use with non-GSSAPI software.

Starting on a Windows client, you can use either SSPI or GSSAPI,
You don't normally mix the two, but you could select which one to use
base on the credentials you have at hand.

> password? Not defined. 

True for GSSAPI it is not defined. But you can get a SSPI credential
from a username and password similiar to what "runas /netonly" does and
use it with SSPI.

The gssklog program (used to get AFS tokens) when run on Windows can
do both of the above. But normally it would either use the KfW provided
gssapi32.dll or the Microsoft SSPI. The -ms option would let you choose
which one to look at for credentials first.

D:\build\bin>gssklog -help
Usage: gssklog [-x] [-principal <user or user@realm>]
[-password <user's password>] [-cell <cell name>] [-pipe] [-silent]
[-lifetime <ticket lifetime in hh[:mm[:ss]]>] [-setpag] [-port <port>]
[-gsiklog] [-server <server>] [-p <Get token for cell containing this path>]
[-ms] [-help]
Where: -x        (obsolete, noop)
        -pipe     read password from stdin
        -silent   silent operation
        -setpag   Create a new setpag before authenticating
        -gsiklog  Use old gsiklog
        -ms       Use MS credentials via sspi before MIT Kerberos

> How does a service get the delegated credential

OpenSSH sshd is a good example for this, in that it can store the
delegated credenential. As you point out in the note, in a web server,
use of the KRB5CCNAME, is not a good choice. I am not aware of any recent
advances in this area, but I know in the past, there have been modifications
to do this. There is also
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-store-cred-02.txt

> For the OP to implement SSPI in WINE GSSAPI alone will not even come

Not sure what you are getting at here.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Michael B Allen <[email-masked]>
Date: Fri, 8 Dec 2006 17:36:40 -0500

On Fri, 08 Dec 2006 15:46:59 -0600

> Not sure what you are getting at here.

Sorry. This was a redirect from the Heimdal list where the OP was asking
about using GSSAPI to implement SSPI for the Wine project. I only CC'd
the kitten list because I wanted them to see my footnote about saving
delegated credentials which I recall was a topic of discussion there. I
should have prefixed the message with some context information.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 08 Dec 2006 16:54:52 -0600

I am on bith the Kitten and Heimdal lists.

I was trying to point out on the client side the same application
could use either SSPI or GSSAPI depending on what credentials
where available. and talk to the same server.

--