Wildcard service principal?

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Wildcard service principal?

Victor Sudakov
Colleagues,

Is a wildcard keytab entry possible?

I use the negotiate_kerberos_auth helper with Squid. I don't care
about matching the service principal name on the server side as long
as the client's principal name and key in the request are valid.

If I could, I would be happy with the 'HTTP/*@MY.REALM' entry in
Squid's keytab.

Tell me why this is a (probably) bad idea and why it is (not)
possible?

PS Heimdal 1.1.0

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Love Hörnquist Åstrand
Victor,


Is a wildcard keytab entry possible?

Kind of, its the reverse though. Its a wildcard from the server code, not the keytab.


I use the negotiate_kerberos_auth helper with Squid. I don't care
about matching the service principal name on the server side as long
as the client's principal name and key in the request are valid.


commit 6239532d9a6c1c847b8eaabd81e3f5ea17af8709
Author: Love Hörnquist Åstrand <[hidden email]>
Date:   Sun Jan 11 21:44:48 2009 +0000

    If no server given, interate over keytab to find a key that can
    decrypt the request. The resulting server principal is what in the
    keytab, the real service can be fetched from.

    

    git-svn-id: <a href="svn://svn.h5l.se/heimdal/trunk/heimdal@24257" class="">svn://svn.h5l.se/heimdal/trunk/heimdal@24257 ec53bebd-3082-4978-b11e-865c3cabbd6b


If I could, I would be happy with the '[hidden email]' entry in
Squid's keytab.


Above code tries to match any entry in the keytab.


Tell me why this is a (probably) bad idea and why it is (not)
possible?

It lowers security a tiny bit, but its still cryptographic security.

its only enabled when the upper layer (GSS) don’t pass in a credential to gss_accept_sec_context()
since the bad part is that its kind of expensive if your is very long.

Love


Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
Love H??rnquist ??strand wrote:

>
>
> > Is a wildcard keytab entry possible?
>
> Kind of, its the reverse though. Its a wildcard from the server code, not the keytab.
>
> >
> > I use the negotiate_kerberos_auth helper with Squid. I don't care
> > about matching the service principal name on the server side as long
> > as the client's principal name and key in the request are valid.
>
>
> commit 6239532d9a6c1c847b8eaabd81e3f5ea17af8709
> Author: Love H??rnquist ??strand <[hidden email]>
> Date:   Sun Jan 11 21:44:48 2009 +0000
>
>     If no server given, interate over keytab to find a key that can
>     decrypt the request. The resulting server principal is what in the
>     keytab, the real service can be fetched from.
>    
>     git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@24257 ec53bebd-3082-4978-b11e-865c3cabbd6b

I think I know what you mean. I am already running
"negotiate_kerberos_auth -s GSS_C_NO_NAME", but please see below.

>
>
> > If I could, I would be happy with the 'HTTP/*@MY.REALM' entry in
> > Squid's keytab.
>
>
> Above code tries to match any entry in the keytab.

But a matching entry must exist. If a request comes for a totally
non-existent entry, like HTTP/[hidden email], then the
authentication request will be rejected.

> >
> > Tell me why this is a (probably) bad idea and why it is (not)
> > possible?
>
> It lowers security a tiny bit, but its still cryptographic security.
>
> its only enabled when the upper layer (GSS) don???t pass in a credential to gss_accept_sec_context()
> since the bad part is that its kind of expensive if your is very long.
>

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Love Hörnquist Åstrand
>>
>>
>>> If I could, I would be happy with the 'HTTP/*@MY.REALM' entry in
>>> Squid's keytab.
>>
>>
>> Above code tries to match any entry in the keytab.
>
> But a matching entry must exist. If a request comes for a totally
> non-existent entry, like HTTP/[hidden email], then the
> authentication request will be rejected.

First, there must be a a entry, you can never really get away from that in Kerberos
 What you can do so is patch the HDB backend have more complicated rules for matching.
Aliases matching only partly does what you want it to do (It allows host/alias@R
to be an alias for host/real@R)

You you need to do is either patch the bdb backend or add a proxy backend.

If this is a simple hack to solve a specific problem i would just add a back to the BDB
backend that uses krb5_principal_match() to find an globing matching.

(also, I would upgrade to the 1.6 branch)

Love


Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
Love H??rnquist ??strand wrote:

> >>> If I could, I would be happy with the 'HTTP/*@MY.REALM' entry in
> >>> Squid's keytab.
> >>
> >>
> >> Above code tries to match any entry in the keytab.
> >
> > But a matching entry must exist. If a request comes for a totally
> > non-existent entry, like HTTP/[hidden email], then the
> > authentication request will be rejected.
>
> First, there must be a a entry, you can never really get away from that in Kerberos
>  What you can do so is patch the HDB backend have more complicated rules for matching.
> Aliases matching only partly does what you want it to do (It allows host/alias@R
> to be an alias for host/real@R)

Is an entry of type HTTP/*@R not possible? Meaning "match any service
requested".

>
> You you need to do is either patch the bdb backend or add a proxy backend.
>
> If this is a simple hack to solve a specific problem i would just add a back to the BDB
> backend that uses krb5_principal_match() to find an globing matching.

I don't quite get what backend and bdb you are referring to.

The negotiate_kerberos_auth is a small plugin using libgssapi and
libkrb5. On start, it locates its keytab in $KRB5_KTNAME and uses SPNs
from there.

I want it to authenticate clients regardless of what server name the
client is requesting, be it HTTP/[hidden email] or
HTTP/[hidden email] or whatever.

Clients receive their tickets from Active Directory of which I have
little to no control. The keytab for the squid service was generated
and given to me by the AD administrator.

>
> (also, I would upgrade to the 1.6 branch)
>

Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
worth while recompiling everything.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Benjamin Kaduk-2
On Wed, 21 Jan 2015, Victor Sudakov wrote:

> Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
> worth while recompiling everything.

You could upgrade to FreeBSD 10 and get a 1.5 Heimdal ... once a 1.6 is
released I will lobby for FreeBSD to import it.

-Ben
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
Benjamin Kaduk wrote:
> On Wed, 21 Jan 2015, Victor Sudakov wrote:
>
> > Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
> > worth while recompiling everything.
>
> You could upgrade to FreeBSD 10 and get a 1.5 Heimdal ... once a 1.6 is
> released I will lobby for FreeBSD to import it.
>

Would this solve the HTTP/*@MY.REALM issue?

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Nico Williams
On Wed, Jan 21, 2015 at 12:55:23PM +0600, Victor Sudakov wrote:

> Benjamin Kaduk wrote:
> > On Wed, 21 Jan 2015, Victor Sudakov wrote:
> >
> > > Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
> > > worth while recompiling everything.
> >
> > You could upgrade to FreeBSD 10 and get a 1.5 Heimdal ... once a 1.6 is
> > released I will lobby for FreeBSD to import it.
> >
>
> Would this solve the HTTP/*@MY.REALM issue?

Yes, kind of.  You wouln't have a wildcard entry in your keytab.
Instead the service code in the library would try every key in the
keytab with matching enctype.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Markus Moeller
In reply to this post by Love Hörnquist Åstrand
Hi Victor,
 
  The helper has an option –s  GSS_C_NO_NAME  which will match what ever is in the keytab.
 
Markus
 
Sent: Tuesday, January 20, 2015 12:21 PM
Subject: Re: Wildcard service principal?
 
Victor,
 

Is a wildcard keytab entry possible?
 
Kind of, its the reverse though. Its a wildcard from the server code, not the keytab.


I use the negotiate_kerberos_auth helper with Squid. I don't care
about matching the service principal name on the server side as long
as the client's principal name and key in the request are valid.
 
 
commit 6239532d9a6c1c847b8eaabd81e3f5ea17af8709
Author: Love Hörnquist Åstrand <[hidden email]>
Date:   Sun Jan 11 21:44:48 2009 +0000
 
    If no server given, interate over keytab to find a key that can
    decrypt the request. The resulting server principal is what in the
    keytab, the real service can be fetched from.

   

    git-svn-id: <A href="svn://svn.h5l.se/heimdal/trunk/heimdal@24257">svn://svn.h5l.se/heimdal/trunk/heimdal@24257 ec53bebd-3082-4978-b11e-865c3cabbd6b
 

If I could, I would be happy with the '[hidden email]' entry in
Squid's keytab.
 
 
Above code tries to match any entry in the keytab.


Tell me why this is a (probably) bad idea and why it is (not)
possible?
 
It lowers security a tiny bit, but its still cryptographic security.
 
its only enabled when the upper layer (GSS) don’t pass in a credential to gss_accept_sec_context()
since the bad part is that its kind of expensive if your is very long.
 
Love
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Markus Moeller
In reply to this post by Victor Sudakov
Hi Victor,

  The helper has an option –s  GSS_C_NO_NAME  which will match what ever is
in the keytab.

Markus

"Victor Sudakov"  wrote in message
news:[hidden email]...

Benjamin Kaduk wrote:
> On Wed, 21 Jan 2015, Victor Sudakov wrote:
>
> > Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
> > worth while recompiling everything.
>
> You could upgrade to FreeBSD 10 and get a 1.5 Heimdal ... once a 1.6 is
> released I will lobby for FreeBSD to import it.
>

Would this solve the HTTP/*@MY.REALM issue?

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
In reply to this post by Markus Moeller
Markus Moeller wrote:
>
>   The helper has an option ???s  GSS_C_NO_NAME  which will match
>   what ever is in the keytab.

Yes, I am already using this option.

BUT!!!

It does not help if a service principal name IS NOT in the keytab.

I want to match ANYTHING, ANY SPN with a valid key, no matter whether
the name does or does not match any name in the keytab.

I don't understand why I cannot communicate this simple idea to you
guys. Perhaps my English is poor. Sorry about that.


--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Russ Allbery-2
Victor Sudakov <[hidden email]> writes:

> It does not help if a service principal name IS NOT in the keytab.

> I want to match ANYTHING, ANY SPN with a valid key, no matter whether
> the name does or does not match any name in the keytab.

You can't do this because Kerberos.  It inherently does not work in the
Kerberos protocol.

That name isn't just a name.  It corresponds to a principal, which in turn
corresponds to a private key, which is what's stored in that keytab.  When
the client goes to authenticate to the server, it authenticates to a
specific principal, which is chosen by the client.  The client obtains a
service ticket for that specific principal from the KDC.  The KDC includes
data encrypted in the key of that principal, which is therefore opaque to
that client.  The client presents that data to the server.  The server
decrypts that data with the key stored in its keytab.  This *has* to
happen for a Kerberos authentication to succeed.

So it doesn't make any sense to say that you want to match *any* principal
chosen by the client, because the client is going to pick a specific name,
that name has to be in the Kerberos KDC with a corresponding key, the
resulting service ticket will be encrypted in that key, and that key then
*must* be in the keytab on the server for the authentication to succeed.
You can't really get around this; it's inherent in the Kerberos protocol.

The closest you might get is to use referrals in the KDC so that the KDC
can try to tell the client which principal it actually wants to use before
it gets the service ticket.

The client and server have to agree on a principal for which the server
has keys in a keytab before the client/server authentication starts.  (You
can't let the server just tell the client what principal to use because
that breaks mutual auth; a malicious server can just tell the client to
use some random other principal under the attacker's control, unrelated to
the resource the client thought it was accessing.)

--
Russ Allbery ([hidden email])              <http://www.eyrie.org/~eagle/>
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
In reply to this post by Nico Williams
Nico Williams wrote:

> On Wed, Jan 21, 2015 at 12:55:23PM +0600, Victor Sudakov wrote:
> > Benjamin Kaduk wrote:
> > > On Wed, 21 Jan 2015, Victor Sudakov wrote:
> > >
> > > > Heimdal 1.1.0 is included in FreeBSD's base system, I don't think it's
> > > > worth while recompiling everything.
> > >
> > > You could upgrade to FreeBSD 10 and get a 1.5 Heimdal ... once a 1.6 is
> > > released I will lobby for FreeBSD to import it.
> > >
> >
> > Would this solve the HTTP/*@MY.REALM issue?
>
> Yes, kind of.  You wouln't have a wildcard entry in your keytab.
> Instead the service code in the library would try every key in the
> keytab with matching enctype.
>

Only if the requested name matches one of the names in the keytab.

I'll give an example. There are two entries in the keytab with the
same key:

HTTP/[hidden email]
HTTP/[hidden email]

If a client comes with a ticket for HTTP/[hidden email]
or even HTTP/[hidden email], it is rejected.

I want to accept the client no matter what service name the ticket is
for. Please tell me why it is not possible.


--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Nico Williams
In reply to this post by Russ Allbery-2
On Wed, Jan 21, 2015 at 08:20:41PM -0800, Russ Allbery wrote:
> Victor Sudakov <[hidden email]> writes:
>
> > It does not help if a service principal name IS NOT in the keytab.
>
> > I want to match ANYTHING, ANY SPN with a valid key, no matter whether
> > the name does or does not match any name in the keytab.
>
> You can't do this because Kerberos.  It inherently does not work in the
> Kerberos protocol.

Well, a service principal can have aliases [with the same keys].

All wildcard matching in a keytab would do is... reduce the number of
entries needed.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
Nico Williams wrote:

> >
> > > It does not help if a service principal name IS NOT in the keytab.
> >
> > > I want to match ANYTHING, ANY SPN with a valid key, no matter whether
> > > the name does or does not match any name in the keytab.
> >
> > You can't do this because Kerberos.  It inherently does not work in the
> > Kerberos protocol.
>
> Well, a service principal can have aliases [with the same keys].
>
> All wildcard matching in a keytab would do is... reduce the number of
> entries needed.

For some reason (unknown to me), Windows hosts began requesting access
to HTTP/[hidden email] instead of
HTTP/[hidden email] (note the case
difference). Such requests are denied by the kerberized server.

I had to create another entry in the keytab with the same key which
fixed the access issue.

If I could have a wildcard entry in the keytab, it would have saved me
the trouble. If tomorrow they all of a sudden begin requesting access
to HTTP/[hidden email] or
HtTp/[hidden email] or whatever, I would have
to create yet another entry and yet another...

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
In reply to this post by Russ Allbery-2
Russ Allbery wrote:

> Victor Sudakov <[hidden email]> writes:
>
> > It does not help if a service principal name IS NOT in the keytab.
>
> > I want to match ANYTHING, ANY SPN with a valid key, no matter whether
> > the name does or does not match any name in the keytab.
>
> You can't do this because Kerberos.  It inherently does not work in the
> Kerberos protocol.
>
> That name isn't just a name.  It corresponds to a principal, which in turn
> corresponds to a private key, which is what's stored in that keytab.  When
> the client goes to authenticate to the server, it authenticates to a
> specific principal, which is chosen by the client.  The client obtains a
> service ticket for that specific principal from the KDC.  The KDC includes
> data encrypted in the key of that principal, which is therefore opaque to
> that client.  The client presents that data to the server.  The server
> decrypts that data with the key stored in its keytab.  This *has* to
> happen for a Kerberos authentication to succeed.
>
> So it doesn't make any sense to say that you want to match *any* principal
> chosen by the client, because the client is going to pick a specific name,
> that name has to be in the Kerberos KDC with a corresponding key, the
> resulting service ticket will be encrypted in that key, and that key then
> *must* be in the keytab on the server for the authentication to succeed.

I agree with the above. However, the key is already in the keytab on
the server. Why would the server care about the SPN requested, if the
encrypted data presented by the client is correct and the encrypted
secret is decryptable?

Consider an example. There is an entry for "host/foo.bar@R" in the
server keytab. The client has contacted the KDC and obtained a service
ticket for "host/FOO.BAR@R" or ""hOsT/fOo.bAr@R"" (because the
Microsoft Kerberos is case insensitive). Is there a reason for the
server to reject the client?  IMHO there is no reason.

Consider another example. The client has contacted the KDC and
obtained a service ticket for "host/foo.bar@R", but the keytab entry
in the server is "host/foo@R". Is there a reason for the
server to reject the client?  IMHO there is no reason again because
"foo" is just the non-canonified form of "foo.bar".


> You can't really get around this; it's inherent in the Kerberos protocol.
>
> The closest you might get is to use referrals in the KDC so that the KDC
> can try to tell the client which principal it actually wants to use before
> it gets the service ticket.

Let's consider that the client has already obtained the ticket with
the correct secret. Now our priority is not to reject the client
unnecessarily being liberal about the requested SPN.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
In reply to this post by Nico Williams
Nico Williams wrote:

> >
> > > It does not help if a service principal name IS NOT in the keytab.
> >
> > > I want to match ANYTHING, ANY SPN with a valid key, no matter whether
> > > the name does or does not match any name in the keytab.
> >
> > You can't do this because Kerberos.  It inherently does not work in the
> > Kerberos protocol.
>
> Well, a service principal can have aliases [with the same keys].

Are the aliases defined in the keytab or in the KDC database?

>
> All wildcard matching in a keytab would do is... reduce the number of
> entries needed.
>

That's what I need :-) I would like to reduce the number of entries I
will have to predict. If I could reduce this infinity to just 1
wildcard entry, I'd be happy.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Love Hörnquist Åstrand
In reply to this post by Victor Sudakov

22 jan. 2015 kl. 10:51 skrev Victor Sudakov <[hidden email]>:

Russ Allbery wrote:
Victor Sudakov <[hidden email]> writes:

It does not help if a service principal name IS NOT in the keytab. 

I want to match ANYTHING, ANY SPN with a valid key, no matter whether
the name does or does not match any name in the keytab.

You can't do this because Kerberos.  It inherently does not work in the
Kerberos protocol.

That name isn't just a name.  It corresponds to a principal, which in turn
corresponds to a private key, which is what's stored in that keytab.  When
the client goes to authenticate to the server, it authenticates to a
specific principal, which is chosen by the client.  The client obtains a
service ticket for that specific principal from the KDC.  The KDC includes
data encrypted in the key of that principal, which is therefore opaque to
that client.  The client presents that data to the server.  The server
decrypts that data with the key stored in its keytab.  This *has* to
happen for a Kerberos authentication to succeed.

So it doesn't make any sense to say that you want to match *any* principal
chosen by the client, because the client is going to pick a specific name,
that name has to be in the Kerberos KDC with a corresponding key, the
resulting service ticket will be encrypted in that key, and that key then
*must* be in the keytab on the server for the authentication to succeed.

I agree with the above. However, the key is already in the keytab on
the server. Why would the server care about the SPN requested, if the
encrypted data presented by the client is correct and the encrypted
secret is decrypt able?

It doesn’t in modern Heimdal if you don’t give a SPN.

The server will try all keys in the keytab with the same enctype if there is no specified SPN, if any of them work, ”happiness”.

If this doesn’t work, that is a different story and that should be fixed.

Love


Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Victor Sudakov
Love H??rnquist ??strand wrote:

[dd]

> > I agree with the above. However, the key is already in the keytab on
> > the server. Why would the server care about the SPN requested, if the
> > encrypted data presented by the client is correct and the encrypted
> > secret is decrypt able?
>
> It doesn???t in modern Heimdal if you don???t give a SPN.

It would be nice to have a hack to "try all keys in the keytab with
the same enctype notwithstanding the SPN."

>
> The server will try all keys in the keytab with the same enctype if
> there is no specified SPN, if any of them work, ???happiness???.

It still requires that a match be found.

>
> If this doesn???t work, that is a different story and that should be fixed.
>

Iterating all keys in the keytab does work.

--
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard service principal?

Love Hörnquist Åstrand

> 22 jan. 2015 kl. 12:45 skrev Victor Sudakov <[hidden email]>:
>
> Love H??rnquist ??strand wrote:
>
> [dd]
>
>>> I agree with the above. However, the key is already in the keytab on
>>> the server. Why would the server care about the SPN requested, if the
>>> encrypted data presented by the client is correct and the encrypted
>>> secret is decrypt able?
>>
>> It doesn???t in modern Heimdal if you don???t give a SPN.
>
> It would be nice to have a hack to "try all keys in the keytab with
> the same enctype notwithstanding the SPN."
>
>>
>> The server will try all keys in the keytab with the same enctype if
>> there is no specified SPN, if any of them work, ???happiness???.
>
> It still requires that a match be found.

That’s what I’m trying to say, it doesn’t match principal, just tries to decrypt using all keys.

A key is required, but that’s Kerberos.

Love


12