[19808] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: GSS API new mechanism integration

daemon@ATHENA.MIT.EDU (Adam Bernstein)
Thu Aug 30 12:24:02 2018

To: =?UTF-8?B?T25kxZllaiBWZWzDrcWhZWs=?= <ondrejvelisek@gmail.com>,
        <krbdev@mit.edu>
From: Adam Bernstein <abernstein@vmware.com>
Message-ID: <5c69e368-d350-8eda-45ad-940dd3072c90@vmware.com>
Date: Thu, 30 Aug 2018 09:22:47 -0700
MIME-Version: 1.0
In-Reply-To: <CAFWcAn5PCYchFPhoNsnQ6Di9-vXFkj3JBRviaX3j=tQiu278Og@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit

Hi Ondřej,

I've implemented two additional GSSAPI mechanisms using the mechglue layer.
    https://github.com/vmware/lightwave/tree/dev/vmdir/gssapi-plugins/unix
    https://github.com/vmware/lightwave/tree/dev/vmdir/gssapi-plugins/srp

Creating the plugin is most of the work. Calling the
gss_init_sec_context() for your plugin is the rest of the effort.
  
https://github.com/vmware/likewise-open/blob/dev/dcerpc/demos/echo_server/echo_client.c

Look at this modified version of echo_client.c for how to call into the
UNIX/SRP and SRP/RPC authentication mechanisms.

UNIX/SRP uses the SRP authentication protocol, but does not require
pre-configuration of an identity provider. It uses existing accounts
found in /etc/passwd and /etc/shadow for authentication. Short story:
the server looks up the user in its passwd file, and parses out and
returns the UNIX Salt value back to the client. This way, the client can
call crypt(pass, salt) to compute the hash value in the server's
/etc/passwd file. This hash value is then used as the SRP key for both
the client and server. The remaining authentication exchanges are SRP
protocol.

The SRP/RPC method requires a pre-existing LDAP directory configuration
with identities configured. In this implementation, that is vmdird. It
is nearly the same protocol as UNIX/SRP, but relies on the SRP "V"
secret be pre-computed and can be obtained by an LDAP lookup by UPN of
the user authenticating. The client can compute the SRP authentication
secrets, as the user knows the password for the account. The server must
retrieve the SRP "V" value from LDAP to complete the SRP server
authentication.

When writing this implementation I encountered the same issues as you,
mainly the lack of a reference implementation for how to write a GSSAPI
plugin and how to force the GSSSPI mechglue layer to call into my
plugins. This code provides working examples for how to make this work.

The trick is constructing the GSS client binding handle. You must call
gss_acquire_cred() with a gss_OID_set_desc structure populated with the
OID for your authentication mech. The next call is to bind your
authentication-specific data to cred_handle is done with
gss_set_cred_option(), the gss_cred_id_t argument. All of this sample
code can be found in the echo_client.c for
rpc_create_srp_auth_identity() method above.

Good luck,
Adam Bernstein

VMware Inc.


On 8/30/18 4:38 AM, Ondřej Velíšek wrote:
> Hey there,
>
> I'm writing diploma thesis and a part of it is developing new GSS API
> mechanism. I'm not able to force services to use it instead of Kerberos.
> I'm not sure if I understand the concept correctly so I think the best is
> to explain my understanding first.
>
> GSS API is just a spec describing interface. Defining contract between two
> (resp 4) software.
> Client - wants to access server and be verified
> GSS API Client library
> Server - wants to verify clients identity
> GSS API Server library
>
> Most likely GSS API Client and server library are at the end the same
> library just copied on two places containing methods for both sides.
>
> lets call Client and Server "Software" and GSS API Server/Client "GSS
> library"
>
> Talking about C it means On the machine there is .so linux library file
> somewhere with implemented GSS library C interface. And the Software loads
> it and calling its methods.
> So they need to have somewhere path to that library. e.g.
> /usr/lib/libgss_krb5.so. I would expect it should be in some config file
> and I will just edit it to point to /usr/lib/libgss_myimpl.so.
>
> The other options is something I found called mechglue. Which is another
> layer between Software and GSS library. So Software can have hard coded the
> path to mechglue.so and call mechglue GSS API methods and mechglue will
> dispatch it to real mechanism configured in /etc/gss/mech (or mech.d/*.conf)
>
> The problem is that when I installed Krb5 I would expect to have kerberos
> configured in /etc/gss/mech so I would just edit it to point to my GSS
> library. But its empty.
>
> What I'm missing? I want to force SSH to use my GSS library and since the
> config option in SSH is just yes/no I would expect that real GSS library
> will be configurable through mechglue. Is that right?
>
> Thnak you!
>
> Wish you beautiful day
>
> Ondrej Velisek
> _______________________________________________
> krbdev mailing list             krbdev@mit.edu
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fkrbdev&amp;data=02%7C01%7Cabernstein%40vmware.com%7C35c98d36d2c14859e2c608d60e6dd1f6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636712262189175674&amp;sdata=b7h1%2BhdS8xPhab7251QA9LtWmbS%2BWm12nZGUa9ca7iA%3D&amp;reserved=0

_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev


home help back first fref pref prev next nref lref last post