Turning off hostname canonicalisation

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Turning off hostname canonicalisation

Andrew Bartlett
As part of our effort to get kerberos working really well in Samba4, I'm
interested to turn off hostname canonicalisation, because it isn't
required in AD realms, it doesn't make much sense anyway for netbios
names and DNS is so often broken on real networks.

Rather than just rip out the code (in our modified heimdal snapshot), I
was looking at instead using a krb5.conf config option, and hoped that I
might get some consensus as to how this should be done, between the two
projects that share the /etc/krb5.conf file (and have done so very well,
I get surprisingly little pain from this).

I'm thinking along the lines of:
[libdefaults]
 hostname_canonicalise = no

This would prevent the krb5 libs doing hostname lookups to obtain a
fully-qualified hostname.

For compatibility I assume it would be 'yes' by default, but Samba would
set it to no in the krb5_init_context routines.  

Does this sound sane?

Andrew Bartlett
--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Altman-4
Andrew:

MIT has already implemented this functionality.
We added

[libdefaults]
  rdns = {no, yes}

It currently defaults to "on" but can be turned off in the profile.

Jeffrey Altman



Andrew Bartlett wrote:

> As part of our effort to get kerberos working really well in Samba4, I'm
> interested to turn off hostname canonicalisation, because it isn't
> required in AD realms, it doesn't make much sense anyway for netbios
> names and DNS is so often broken on real networks.
>
> Rather than just rip out the code (in our modified heimdal snapshot), I
> was looking at instead using a krb5.conf config option, and hoped that I
> might get some consensus as to how this should be done, between the two
> projects that share the /etc/krb5.conf file (and have done so very well,
> I get surprisingly little pain from this).
>
> I'm thinking along the lines of:
> [libdefaults]
>  hostname_canonicalise = no
>
> This would prevent the krb5 libs doing hostname lookups to obtain a
> fully-qualified hostname.
>
> For compatibility I assume it would be 'yes' by default, but Samba would
> set it to no in the krb5_init_context routines.  
>
> Does this sound sane?
>
> Andrew Bartlett
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Kenneth G Raeburn
On Sep 9, 2005, at 20:10, Jeffrey Altman wrote:
> MIT has already implemented this functionality.
> We added
>
> [libdefaults]
>   rdns = {no, yes}
>
> It currently defaults to "on" but can be turned off in the profile.

No, this is different functionality.

MIT's current code does basically this:

   1) get hostname from user/app
   2) call getaddrinfo on hostname
   3) pull out ai_canonname, the canonical name, if non-null
   4) if rdns=yes:
     a) call getnameinfo(NI_NAMEREQD) on first address
     b) if successful, use returned name

What Andrew's proposing basically cuts this off after step 1.  The  
user provides a name, we drop it into a principal and send it off to  
the KDC.

It sounds like a good thing, except ... if a host is being a Samba  
client, does that mean it's talking to the AD for all its Kerberos  
communication?  It won't be talking to, say, an MIT KDC that expects  
fully qualified canonical name to be used in the principal name?  
Changing /etc/krb5.conf will affect all Kerberos applications on the  
machine; if that's not the right result, then Samba would need its  
own config file, or we should use a different way to switch it off.

BTW, Andrew's original message seems to conflate "canonical" and  
"fully qualified" names.  A name can be fully qualified without being  
canonical.  I assumed from his description that he wants any sort of  
name lookup and transformation shut off....

Ken
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Altman-4
Ken Raeburn wrote:

> On Sep 9, 2005, at 20:10, Jeffrey Altman wrote:
>
>> MIT has already implemented this functionality.
>> We added
>>
>> [libdefaults]
>>   rdns = {no, yes}
>>
>> It currently defaults to "on" but can be turned off in the profile.
>
>
> No, this is different functionality.
>
> MIT's current code does basically this:
>
>   1) get hostname from user/app
>   2) call getaddrinfo on hostname
>   3) pull out ai_canonname, the canonical name, if non-null
>   4) if rdns=yes:
>     a) call getnameinfo(NI_NAMEREQD) on first address
>     b) if successful, use returned name
>
> What Andrew's proposing basically cuts this off after step 1.  The  user
> provides a name, we drop it into a principal and send it off to  the KDC.
>
> It sounds like a good thing, except ... if a host is being a Samba
> client, does that mean it's talking to the AD for all its Kerberos
> communication?  It won't be talking to, say, an MIT KDC that expects
> fully qualified canonical name to be used in the principal name?  
> Changing /etc/krb5.conf will affect all Kerberos applications on the
> machine; if that's not the right result, then Samba would need its  own
> config file, or we should use a different way to switch it off.
>
> BTW, Andrew's original message seems to conflate "canonical" and  "fully
> qualified" names.  A name can be fully qualified without being
> canonical.  I assumed from his description that he wants any sort of
> name lookup and transformation shut off....
>
> Ken

You are correct.  The "rdns" addition we made allows the configuration
to disable the worst of the hacks.

I agree that we should have the ability to disable this after step 1
as well.   There is a need for an application to be able to state
explicitly what the hostname should be.  Especially in the Windows world
which often relies on the first component of the hostname as obtained
via a Netbios lookup not a DNS lookup.

Jeffrey Altman

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Andrew Bartlett
On Fri, 2005-09-09 at 20:34 -0400, Jeffrey Altman wrote:

> Ken Raeburn wrote:
> > On Sep 9, 2005, at 20:10, Jeffrey Altman wrote:
> >
> >> MIT has already implemented this functionality.
> >> We added
> >>
> >> [libdefaults]
> >>   rdns = {no, yes}
> >>
> >> It currently defaults to "on" but can be turned off in the profile.
> >
> >
> > No, this is different functionality.
> >
> > MIT's current code does basically this:
> >
> >   1) get hostname from user/app
> >   2) call getaddrinfo on hostname
> >   3) pull out ai_canonname, the canonical name, if non-null
> >   4) if rdns=yes:
> >     a) call getnameinfo(NI_NAMEREQD) on first address
> >     b) if successful, use returned name
> >
> > What Andrew's proposing basically cuts this off after step 1.  The  user
> > provides a name, we drop it into a principal and send it off to  the KDC.
> >
> > It sounds like a good thing, except ... if a host is being a Samba
> > client, does that mean it's talking to the AD for all its Kerberos
> > communication?  It won't be talking to, say, an MIT KDC that expects
> > fully qualified canonical name to be used in the principal name?  
> > Changing /etc/krb5.conf will affect all Kerberos applications on the
> > machine; if that's not the right result, then Samba would need its  own
> > config file, or we should use a different way to switch it off.
> >
> > BTW, Andrew's original message seems to conflate "canonical" and  "fully
> > qualified" names.  A name can be fully qualified without being
> > canonical.  I assumed from his description that he wants any sort of
> > name lookup and transformation shut off....
> >
> > Ken
>
>
> You are correct.  The "rdns" addition we made allows the configuration
> to disable the worst of the hacks.
>
> I agree that we should have the ability to disable this after step 1
> as well.   There is a need for an application to be able to state
> explicitly what the hostname should be.  Especially in the Windows world
> which often relies on the first component of the hostname as obtained
> via a Netbios lookup not a DNS lookup.
Exactly.

In the past, Samba did this by calling the mk_req_extended (and then
using the name from the SPNEGO negtokeninit), but this was disgusting,
and at the wrong layer.  I'm trying in Samba4 to use real GSSAPI, and so
I need a way to specify this via that interface.  

I'm not sure if a krb5.conf option is the 'right way' to do this:  but I
can see it being useful beyond Samba, and for general GSSAPI apps in AD
realms.  Samba would set this to disable DNS in our wrapper for
krb5_init_context, perhaps only if there wasn't an explicit entry in the
krb5.conf.  (Setting options on the krb5_context under GSSAPI is another
matter, but I have to deal with that anyway).

How are MIT/Heimdal realms coping with windows clients, which I presume
don't do such fqdn resolution.  Is the concept of servicePrincipalName
spreading to cope, or are there just multiple principals and keytab
entries being created?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Altman-4
Andrew Bartlett wrote:

> How are MIT/Heimdal realms coping with windows clients, which I presume
> don't do such fqdn resolution.  Is the concept of servicePrincipalName
> spreading to cope, or are there just multiple principals and keytab
> entries being created?

Currently, large numbers of principal names and keytab entries are being
created to deal with this issue.


Jeffrey Altman



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Andrew Bartlett
On Fri, 2005-09-09 at 21:00 -0400, Jeffrey Altman wrote:
> Andrew Bartlett wrote:
>
> > How are MIT/Heimdal realms coping with windows clients, which I presume
> > don't do such fqdn resolution.  Is the concept of servicePrincipalName
> > spreading to cope, or are there just multiple principals and keytab
> > entries being created?
>
> Currently, large numbers of principal names and keytab entries are being
> created to deal with this issue.

Likewise, is there any move to at least allow case insensitivity in
principal names or keytab entries?  I know the Samba patch to allow this
(in the member server, presumably for an AD KDC) is pretty ugly...

(We normally join the domain and get a password, so take any incoming
name, but for some reason we also have AD sites which refuse to give
machine trust accounts to their unix servers, so hand out keytabs).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Hutzelman
In reply to this post by Jeffrey Altman-4


On Friday, September 09, 2005 21:00:52 -0400 Jeffrey Altman
<[hidden email]> wrote:

> Andrew Bartlett wrote:
>
>> How are MIT/Heimdal realms coping with windows clients, which I presume
>> don't do such fqdn resolution.  Is the concept of servicePrincipalName
>> spreading to cope, or are there just multiple principals and keytab
>> entries being created?
>
> Currently, large numbers of principal names and keytab entries are being
> created to deal with this issue.

Someday, I'd love to see MIT and/or Heimdal add real principal name
aliasing, which would allow better handling for this case than is currently
possible.  As to whether any of the implementors are likely to spend time
on it, I don't know.

I very much support the idea of a libdefaults setting to turn of DNS
resolution entirely.  Among other things, this would allow compliance with
RFC4120 section 1.3, which says:

   Implementations of Kerberos and protocols based on Kerberos MUST NOT
   use insecure DNS queries to canonicalize the hostname components of
   the service principal names (i.e., they MUST NOT use insecure DNS
   queries to map one name to another to determine the host part of the
   principal name with which one is to communicate).


However, I object to the name proposed by Andrew, on the grounds that a
significant portion of users are likely to misspell it, due to a systematic
difference in spelling between British and American English (In American
English, we spell -ize with a 'z').

Since a misspelling would result in unintended and potentially insecure
behavior (depending on which setting is the default) and would not trigger
an error message, let's pick a name which does not have this problem.

-- Jeff
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Andrew Bartlett
On Fri, 2005-09-09 at 23:54 -0400, Jeffrey Hutzelman wrote:

>
> On Friday, September 09, 2005 21:00:52 -0400 Jeffrey Altman
> <[hidden email]> wrote:
>
> > Andrew Bartlett wrote:
> >
> >> How are MIT/Heimdal realms coping with windows clients, which I presume
> >> don't do such fqdn resolution.  Is the concept of servicePrincipalName
> >> spreading to cope, or are there just multiple principals and keytab
> >> entries being created?
> >
> > Currently, large numbers of principal names and keytab entries are being
> > created to deal with this issue.
>
> Someday, I'd love to see MIT and/or Heimdal add real principal name
> aliasing, which would allow better handling for this case than is currently
> possible.  As to whether any of the implementors are likely to spend time
> on it, I don't know.
Samba4 already has this feature (naturally, given we are after AD
behaviour), but the more useful point I wanted to make is that I didn't
find it hard to add, particularly to an ldap-like backend (you just
search for one of any of the names on a record).

> I very much support the idea of a libdefaults setting to turn of DNS
> resolution entirely.  Among other things, this would allow compliance with
> RFC4120 section 1.3, which says:
>
>    Implementations of Kerberos and protocols based on Kerberos MUST NOT
>    use insecure DNS queries to canonicalize the hostname components of
>    the service principal names (i.e., they MUST NOT use insecure DNS
>    queries to map one name to another to determine the host part of the
>    principal name with which one is to communicate).
>
>
> However, I object to the name proposed by Andrew, on the grounds that a
> significant portion of users are likely to misspell it, due to a systematic
> difference in spelling between British and American English (In American
> English, we spell -ize with a 'z').
>
> Since a misspelling would result in unintended and potentially insecure
> behavior (depending on which setting is the default) and would not trigger
> an error message, let's pick a name which does not have this problem.
:-)

fqdn_lookup?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Altman-4
Andrew Bartlett wrote:

> fqdn_lookup?

Since we already have "rdns" to disable the reverse dns lookups,
how about "fdns" to disable the forward dns lookups?

Jeffrey Altman


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Andrew Bartlett
On Sat, 2005-09-10 at 06:39 -0400, Jeffrey Altman wrote:
> Andrew Bartlett wrote:
>
> > fqdn_lookup?
>
> Since we already have "rdns" to disable the reverse dns lookups,
> how about "fdns" to disable the forward dns lookups?

The only thought I have on that is 'cryptic'.  But as we have the
precedent, I'm inclined to follow.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Altman-4
Andrew Bartlett wrote:

> On Sat, 2005-09-10 at 06:39 -0400, Jeffrey Altman wrote:
>
>>Andrew Bartlett wrote:
>>
>>
>>>fqdn_lookup?
>>
>>Since we already have "rdns" to disable the reverse dns lookups,
>>how about "fdns" to disable the forward dns lookups?
>
>
> The only thought I have on that is 'cryptic'.  But as we have the
> precedent, I'm inclined to follow.
>
> Andrew Bartlett
I want to avoid any use of the term "canonicalize" not only because
of spelling but because there are so many forms of canonicalization
and we don't want to disable all of them.   In a sense, anything we
choose is going to end up being a bit cryptic.

Jeffrey Altman


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Markus Moeller
In reply to this post by Andrew Bartlett
Sorry, I couldn't follow the whole discussion about canonicalisation. I have
in my apps also issues with canoncalisation and like to understand if your
discussion would help my too.Where does the canonicalisation take place in
your case ? In my case the canonicalisation is done when calling
gss_import_name with type GSS_C_NT_HOSTBASED_SERVICE  and the gss service
service@hostname, but if  I use GSS_C_NULL_OID then I have to provide the
correct Kerberos principal, as no canonicalisation is performed. So there is
no need for a global krb5.conf flag or are there other places where
canonicalisation is done inside the Kerberos code ?

The other issue I see in enterprise environments is the use of CNAMEs and
Global Server Load Balancing for load balancing, disaster recovery or simple
failover . In these cases canonicalisation is very useful since you wouldn't
need to synchronise keytabs on different systems. (it may not be as secure,
but you could mitigate the risk in other ways)

Example:
A-record host1.test.com 10.10.10.1
               host2.test.com 10.10.10.2

CNAME app.test.com   host1.test.com 10.10.10.1

If I now access app.test.com the canonicalisation gives me host1.name.com
and I need a keytab of service/host1.test.com on host host1. In disaster
case the CNAME changes to (GSLB would do this automatically)

CNAME app.test.com host2.test.com 10.10.10.2

and I need a keytab with service/host2.test.com on host2. Without
canonicalisation I would need to create keytab for app.test.com and
distribute to every system, which can be painful in a bigger environment. So
I see a need to keep canonicalisation on a service by service case and not
as a global switch.

Thank you
Markus

----- Original Message -----
From: "Andrew Bartlett" <[hidden email]>
To: "Jeffrey Altman" <[hidden email]>
Cc: <[hidden email]>; <[hidden email]>
Sent: Saturday, September 10, 2005 11:41 AM
Subject: Re: Turning off hostname canonicalisation



Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Henry B. Hotz
In reply to this post by Andrew Bartlett
OK.

As implied by my question, I think it should be settable by "service".  
I can imagine needing one setting to support the SPNEGO stuff for web,  
but a different setting for kerberized telnet.  Hope that doesn't make  
it "really hard" to do right though.

On Sep 12, 2005, at 10:14 AM, Jeffrey Altman wrote:

> The answer is 'no'.  Settings in [appdefaults] are not for reading by
> the Kerberos libraries.  They are for reading by the application.
>
> Jeffrey Altman
>
>
> Henry B. Hotz wrote:
>
>> As another branch of this subject tree:  The option being discussed is
>> for [libdefaults].  Will the parsing code pick it up in [appdeafaults]
>> as well?  I would imagine that different app's might be coded
>> differently and might need different behavior to work correctly.
>>
>> On Sep 12, 2005, at 9:02 AM, [hidden email] wrote:
>>
>>> Without
>>> canonicalisation I would need to create keytab for app.test.com and
>>> distribute to every system, which can be painful in a bigger
>>> environment. So
>>> I see a need to keep canonicalisation on a service by service case
>>> and  not
>>> as a global switch.
>>
>> ----------------------------------------------------------------------
>> --
>> ----
>> The opinions expressed in this message are mine,
>> not those of Caltech, JPL, NASA, or the US Government.
>> [hidden email], or [hidden email]
>>
>> _______________________________________________
>> krbdev mailing list             [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

hartmans
In reply to this post by Jeffrey Altman-4
>>>>> "Jeffrey" == Jeffrey Altman <[hidden email]> writes:

    Jeffrey> Andrew: MIT has already implemented this functionality.
    Jeffrey> We added

    Jeffrey> [libdefaults] rdns = {no, yes}

    Jeffrey> It currently defaults to "on" but can be turned off in
    Jeffrey> the profile.

    Jeffrey> Jeffrey Altman



    Jeffrey> Andrew Bartlett wrote:
    >> As part of our effort to get kerberos working really well in
    >> Samba4, I'm interested to turn off hostname canonicalisation,
    >> because it isn't required in AD realms, it doesn't make much
    >> sense anyway for netbios names and DNS is so often broken on
    >> real networks.
    >>
    >> Rather than just rip out the code (in our modified heimdal
    >> snapshot), I was looking at instead using a krb5.conf config
    >> option, and hoped that I might get some consensus as to how
    >> this should be done, between the two projects that share the
    >> /etc/krb5.conf file (and have done so very well, I get
    >> surprisingly little pain from this).
    >>
    >> I'm thinking along the lines of: [libdefaults]
    >> hostname_canonicalise = no
    >>
    >> This would prevent the krb5 libs doing hostname lookups to
    >> obtain a fully-qualified hostname.
    >>
    >> For compatibility I assume it would be 'yes' by default, but
    >> Samba would set it to no in the krb5_init_context routines.
    >>
    >> Does this sound sane?
    >>
    >> Andrew Bartlett
    >>
    >>
    >> ------------------------------------------------------------------------
    >>
    >> _______________________________________________ krbdev mailing
    >> list [hidden email]
    >> https://mailman.mit.edu/mailman/listinfo/krbdev
    Jeffrey> _______________________________________________ krbdev
    Jeffrey> mailing list [hidden email]
    Jeffrey> https://mailman.mit.edu/mailman/listinfo/krbdev

This is broken.  If we're going to add a knob it should implement the
RFc 4120 behavior not some behavior between the current code and 4120.

I don't think we have shipped this yet have we?

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

hartmans
In reply to this post by Andrew Bartlett
>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:

    Andrew> On Fri, 2005-09-09 at 21:00 -0400, Jeffrey Altman wrote:
    >> Andrew Bartlett wrote:
    >>
    >> > How are MIT/Heimdal realms coping with windows clients, which
    >> I presume > don't do such fqdn resolution.  Is the concept of
    >> servicePrincipalName > spreading to cope, or are there just
    >> multiple principals and keytab > entries being created?
    >>
    >> Currently, large numbers of principal names and keytab entries
    >> are being created to deal with this issue.

    Andrew> Likewise, is there any move to at least allow case
    Andrew> insensitivity in principal names or keytab entries?  I
    Andrew> know the Samba patch to allow this (in the member server,
    Andrew> presumably for an AD KDC) is pretty ugly...

We're going to do whatever the Kerberos working group ends up doing.
I don't think anyone has proposed case insensitivity there although
there has been a proposal to ask the KDC for a list of names by which
the current service can be known.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

hartmans
In reply to this post by Andrew Bartlett
>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:
    Andrew> In the past, Samba did this by calling the mk_req_extended
    Andrew> (and then using the name from the SPNEGO negtokeninit),
    Andrew> but this was disgusting, and at the wrong layer.  I'm
    Andrew> trying in Samba4 to use real GSSAPI, and so I need a way
    Andrew> to specify this via that interface.


There's a way in GSSAPI to pass in a raw principal name; take a look
at RFc 1964.

--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Jeffrey Hutzelman
In reply to this post by hartmans


On Monday, September 12, 2005 03:24:08 PM -0400 Sam Hartman
<[hidden email]> wrote:

>>>>>> "Andrew" == Andrew Bartlett <[hidden email]> writes:
>
>     Andrew> On Fri, 2005-09-09 at 21:00 -0400, Jeffrey Altman wrote:
>     >> Andrew Bartlett wrote:
>     >>
>     >> > How are MIT/Heimdal realms coping with windows clients, which
>     >> I presume > don't do such fqdn resolution.  Is the concept of
>     >> servicePrincipalName > spreading to cope, or are there just
>     >> multiple principals and keytab > entries being created?
>     >>
>     >> Currently, large numbers of principal names and keytab entries
>     >> are being created to deal with this issue.
>
>     Andrew> Likewise, is there any move to at least allow case
>     Andrew> insensitivity in principal names or keytab entries?  I
>     Andrew> know the Samba patch to allow this (in the member server,
>     Andrew> presumably for an AD KDC) is pretty ugly...
>
> We're going to do whatever the Kerberos working group ends up doing.
> I don't think anyone has proposed case insensitivity there although
> there has been a proposal to ask the KDC for a list of names by which
> the current service can be known.

The current Kerberos specification contains nothing which would prevent a
KDC from allowing a service to be known by multiple "aliases", such that it
will issue tickets for any of those aliases using the same key.  It is my
understanding that this is essentially how AD SPN's work, and I'd be very
happy to see a similar feature in other KDC's.

I would consider case-insensitive lookups of service principals in the KDB
to be an example of such aliases, provided the ticket issued by the KDC
uses the same case as the request.  Normally I would see little value in
such functionality, as existing specifications do recommend case-folding of
hostnames before they are used to construct service principal names.
Nonetheless, if there are clients widely deployed which do not do this, it
would seem useful for KDC's to have such a feature, and I do not believe it
would be in conflict with the Kerberos spec.


As far as case-insensitive matching in keytab files goes, I don't think
that's an issue for standardization at all.  The choice of what service
principals to use is entirely up to the application protocol and its
implementations.  I would be disappointed to see implementations in which
case-insensitive matching of keytab entries could not be disabled.

-- Jeff
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

hartmans
>>>>> "Jeffrey" == Jeffrey Hutzelman <[hidden email]> writes:

    Jeffrey> I would consider case-insensitive lookups of service
    Jeffrey> principals in the KDB to be an example of such aliases,
    Jeffrey> provided the ticket issued by the KDC uses the same case
    Jeffrey> as the request.  Normally I would see little value in
    Jeffrey> such functionality, as existing specifications do
    Jeffrey> recommend case-folding of hostnames before they are used
    Jeffrey> to construct service principal names. Nonetheless, if
    Jeffrey> there are clients widely deployed which do not do this,
    Jeffrey> it would seem useful for KDC's to have such a feature,
    Jeffrey> and I do not believe it would be in conflict with the
    Jeffrey> Kerberos spec.


Yes.  However I don't think supporting case insensitive names in a
keytab works this way in an interoperable manner.

--Sam

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Turning off hostname canonicalisation

Nicolas Williams
In reply to this post by Jeffrey Hutzelman
On Mon, Sep 12, 2005 at 04:03:44PM -0400, Jeffrey Hutzelman wrote:

>
>
> On Monday, September 12, 2005 03:24:08 PM -0400 Sam Hartman
> <[hidden email]> wrote:
>
> >>>>>>"Andrew" == Andrew Bartlett <[hidden email]> writes:
> >
> >    Andrew> On Fri, 2005-09-09 at 21:00 -0400, Jeffrey Altman wrote:
> >    >> Andrew Bartlett wrote:
> >    >>
> >    >> > How are MIT/Heimdal realms coping with windows clients, which
> >    >> I presume > don't do such fqdn resolution.  Is the concept of
> >    >> servicePrincipalName > spreading to cope, or are there just
> >    >> multiple principals and keytab > entries being created?
> >    >>
> >    >> Currently, large numbers of principal names and keytab entries
> >    >> are being created to deal with this issue.
> >
> >    Andrew> Likewise, is there any move to at least allow case
> >    Andrew> insensitivity in principal names or keytab entries?  I
> >    Andrew> know the Samba patch to allow this (in the member server,
> >    Andrew> presumably for an AD KDC) is pretty ugly...
> >
> >We're going to do whatever the Kerberos working group ends up doing.
> >I don't think anyone has proposed case insensitivity there although
> >there has been a proposal to ask the KDC for a list of names by which
> >the current service can be known.
>
> The current Kerberos specification contains nothing which would prevent a
> KDC from allowing a service to be known by multiple "aliases", such that it
> will issue tickets for any of those aliases using the same key.  It is my
> understanding that this is essentially how AD SPN's work, and I'd be very
> happy to see a similar feature in other KDC's.
>
> I would consider case-insensitive lookups of service principals in the KDB
> to be an example of such aliases, provided the ticket issued by the KDC
> uses the same case as the request.  Normally I would see little value in
> such functionality, as existing specifications do recommend case-folding of
> hostnames before they are used to construct service principal names.
> Nonetheless, if there are clients widely deployed which do not do this, it
> would seem useful for KDC's to have such a feature, and I do not believe it
> would be in conflict with the Kerberos spec.
>
>
> As far as case-insensitive matching in keytab files goes, I don't think
> that's an issue for standardization at all.  The choice of what service
> principals to use is entirely up to the application protocol and its
> implementations.  I would be disappointed to see implementations in which
> case-insensitive matching of keytab entries could not be disabled.

The proposed set/change password version 2 protocol deals with principal
aliasing...

Nico
--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
123