[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using GSSAPI with specific providers





Michael B Allen wrote:

> 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" <hotz@jpl.nasa.gov> 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.
> 

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.

> For example, how do you get a gss_cred_id_t from a username and
> 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
> in a form that can be used with Kerberos aware software like libcurl or
> the pgsql driver? Not defined [1].

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


> 
> 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.

Not sure what you are getting at here.

> 
> 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.
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444