Re: Iterate over server credentials

[Benjamin Kaduk]

On Wed, Mar 22, 2017 at 03:48:21PM -0400, Dylan Klomparens wrote:
> Hello,
> 
> I'm writing a program that accepts Kerberos authentication using the
> GSSAPI. The program acquires credentials using gss_acquire_cred_from() with
> a keytab specified, and this is working properly. The keytab has multiple
> principals stored in it. I want to output all the principals that were
> acquired, so I tried to use gss_inquire_cred() to find out and
> gss_display_name() to print them. This allows me to output the first
> principal in the keytab, but only the first one. Is there a way to output
> all of them? How can I iterate through all the principals acquired from a
> single keytab and output their names?

RFC 2743 is pretty clear that a GSS credential handle can represent
only a single (named) entity, though it may have credentials for
that entity with multiple mechanisms.  Since there is only one
GSS name associated with the credential; there is no need to
iterate.

That said, for the case where the kerberos keytab in question is the
default location (/etc/krb5.keytab, or what is specified by the
KRB5KTNAME environment variable), gss_accept_sec_context() with
GSS_C_NO_CREDENTIAL as the acceptor credential handle will
automatically search through all identities in the keytab and use
any of them, if they match the message from the client.

> Once I accept a security context, the program is authenticating correctly,
> so it stands to reason that I'm legitimately acquiring multiple credentials
> from the same keytab.

What you have said here is not enough information to establish your
conclusion.  How do we know what names the initiators are trying to
use to contact the service?

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Iterate over server credentials

[Dylan Klomparens]

Hello,

I'm writing a program that accepts Kerberos authentication using the
GSSAPI. The program acquires credentials using gss_acquire_cred_from() with
a keytab specified, and this is working properly. The keytab has multiple
principals stored in it. I want to output all the principals that were
acquired, so I tried to use gss_inquire_cred() to find out and
gss_display_name() to print them. This allows me to output the first
principal in the keytab, but only the first one. Is there a way to output
all of them? How can I iterate through all the principals acquired from a
single keytab and output their names?

Once I accept a security context, the program is authenticating correctly,
so it stands to reason that I'm legitimately acquiring multiple credentials
from the same keytab.

(Please forgive any mixups in terminology I may have made, I'm not fully
versed in the Kerberos vocabulary.)

Thanks,
-- Dylan Klomparens

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: What is the interaction for Kerberos in a proxy environment?

[Joshua Schaeffer]

On Tue, Mar 21, 2017 at 4:23 PM, chen dong  wrote:

> I am not sure that my statement is right here. If I am wrong, please
> correct me.
>
> As Kerberos protocol works atop of TCP protocol. Kerberos protocol has its
> own different implementation such MIT Kerberos. And on top of Kerberos,
> there is a virtual layer SASL - simple authentication and security layer,
> this SASL layer can use different mechanism including Kerberos. There is a
> up layer implementation called GSSAPI - generic security system API. It
> also holds different mechanisms underneath including Kerberos. no sure the
> relation ship between SASL and GSSAPI.
>
>
I thought I chime in about this questions here as I want to make sure my
own understanding is also correct. So I'll give my own interpretation and
let smarter people correct me :)

I wouldn't call SASL a virtual layer, but more of a sandwich layer. SASL is
a security framework that is used to allow two protocols to communicate
with each other using a common, negotiated authentication mechanism. The
common examples are:

   - LDAP and Kerberos
   - IMAP and SMTP (I think)

I only work with LDAP and Kerberos so that's the example I go with. SASL
allows any implementation of the Kerberos protocol (MIT, Heimdal, etc) to
securely communicate with any implementation of the LDAP protocol
(OpenLDAP, Apache DS, Sun ONE, etc). The SASL protocol does not provide
security or authentication, it is a means by which the protocols can
communicate a common mechanism by which they then can establish security
and authentication. It does not pass the secure messages between the two
protocols itself. In the case of LDAP and Kerberos the most common
mechanism by which the two protocols can communicate is GSSAPI. Both LDAP
and Kerberos understand the GSSAPI implementation (a.k.a. they provide that
application programming interface) so when SASL is used each program agrees
to use GSSAPI as it is common between them.

GSSAPI is not a protocol, but an API that allows the two programs to send
secure messages. The API itself does not provide security, merely a
mechanism (a "hook" so to speak) that the two programs can commonly use to
securely communicate with each other. Without it every program would have
to know how speak to individual programs. Obviously this is the point of
API's in general, to allow systems to connect to other systems without
direct implementation.

In my own documentation on setting up OpenLDAP with MIT Kerberos I wrote
this about SASL and GSSAPI. It's just a rehash of what I just said, but I'd
be interested to see if anyone can point out mistakes I made in the
description:

The integration with SASL needs to be completed. Several packages need to
> be installed and configured. The first is to install SASL and GSSAPI.
> Because we are using the MIT Kerberos implementation, the MIT GSSAPI
> package will be used. SASL or Simple Authentication and Security Layer is a
> security framework that allows two protocols to authenticate, securely, to
> each other. In this case we need the LDAP protocol which is implemented by
> slapd to authenticate with the Kerberos protocol which is implemented by
> MIT Kerberos. SASL requires that a common auth mechanism be used between
> the two protocols. The mechanism must be supported by both protocols in
> order to be used. SASL does not provide the authentication but rather a
> layer or space that the two protocols can communicate an authentication
> mechanism. The mechanism here is GSSAPI. This mechanism doesn’t provide the
> authentication either, however it does provide an API that allows
> applications and protocols to securely communicate to each other using the
> API.


Again, I'm not an expert on any of these protocols, implementations, or
frameworks so I'd be interested if anybody sees incorrect statements in my
understanding. As far as your question about the proxy environment, I'm in
the dark, and somebody else will have to comment.

Thanks,
Joshua

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos