SPN Canonicalization (was: Re: [neon] Re: neon, SSPI,andmod_auth_kerb) - Kerberos

This is a discussion on SPN Canonicalization (was: Re: [neon] Re: neon, SSPI,andmod_auth_kerb) - Kerberos ; [Removing subversion and adding comp.protocols.kerberos.] --On Friday, July 22, 2005 11:30 AM +0100 Joe Orton wrote: > There is some discussion of this issue in the neon list archive; > the issue is AIUI that mod_auth_kerb *does* canonicalize the > ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: SPN Canonicalization (was: Re: [neon] Re: neon, SSPI,andmod_auth_kerb)

  1. SPN Canonicalization (was: Re: [neon] Re: neon, SSPI,andmod_auth_kerb)

    [Removing subversion and adding comp.protocols.kerberos.]

    --On Friday, July 22, 2005 11:30 AM +0100 Joe Orton
    wrote:

    > There is some discussion of this issue in the neon list archive;
    > the issue is AIUI that mod_auth_kerb *does* canonicalize the
    > hostname but neon does not. neon doesn't canonicalize the server
    > hostname in general because doing so would break name-based
    > vhosting; I guess it could do so solely for use in the Kerberos
    > principal, but that seems a bit dubious.


    Yeah, this is a messy, long-standing, and unresolved issue in
    kerberos. In theory canonicalization introduces a potential MITM
    attack which essentially undermines mutual authentication; in
    practice, everyone does it. This is apparently to be addressed in
    future protocol mods, but it's unclear what to do in software that
    actually needs to work today. Read on for details. Maybe this could
    update the kerberos FAQ?

    The question is: should an application canonicalize a hostname
    entered by a user when forming the SPN?

    Defining terms:

    SPN = serviceName/HOST@REALM
    eg HTTP/proteomics.mayo.edu@MFAD.MFROOT.ORG

    where SPN is the Service Principle Name, the name of the
    kerberos principle that the service uses to
    authenticate itself to the client (so called
    "mutual auth").
    serviceName (eg HTTP) is the (case sensitive[1]) protocol
    specific service name established by convention.
    HOST (eg proteomics.mayo.edu) is the host name of the
    machine the service is running on. This is the
    part we're wondering about.
    REALM (eg MFAD.MFROOT.ORG) is the name of the kerberos
    realm and is often implicit.

    Canonicalization is essentially gethostbyaddr(gethostbyname(host))
    where host is the name provided by the user.

    I've done some googling on this issue and the clearest statement I
    can yet find comes at the end of section 1.3 in RFC4120, which states:

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

    [...]
    > Implementation note: Many current implementations do some degree
    > of canonicalization of the provided service name, often using DNS
    > even though it creates security problems. However, there is no
    > consistency among implementations as to whether the service name
    > is case folded to lowercase or whether reverse resolution is
    > used. To maximize interoperability and security, applications
    > SHOULD provide security mechanisms with names that result from
    > folding the user- entered name to lowercase without performing
    > any other modifications or canonicalization.


    Clear as mud? So it seems like we're left with a choice between
    interoperability and correctness. Almost all other discussion I find
    of this issue seem to indicate that canonicalization is performed in
    practice. Firefox and IE definitely do it. See also question 2.14
    in the Kerberos FAQ:
    ,
    and numerous previous discussions on comp.protocols.kerberos such as
    this thread on load balancing and kerberos:
    .

    Samba seems to work around this problem by creating a skillion
    different keytab entries like:

    3 HTTP/proteomics.mayo.edu@MFAD.MFROOT.ORG
    3 HTTP/proteomics@MFAD.MFROOT.ORG
    3 HTTP/PROTEOMICS@MFAD.MFROOT.ORG
    3 HTTP/PROTEOMICS.mayo.edu@MFAD.MFROOT.ORG
    3 HTTP/proteomics.MFAD.MFROOT.ORG@MFAD.MFROOT.ORG
    3 HTTP/proteomics.mfad.mfroot.org@MFAD.MFROOT.ORG

    and many more besides these (with different salts?). See
    .
    There's an additional problem with samba, active directory validated
    writes, and disjoint namespaces that I'll save for another time.

    It seems to my uneducated eye that really GSSAPI should be such that
    we simply hand it "HTTP" along with the host name entered by the user
    and it figures out the rest. Alas, it is not so. What to do is
    anyone's guess.

    Anyone care to jump in here?

    -c

    [1] Services names are supposed to be lower case; other examples
    include "host" and "imap". "HTTP" is apparently a happy gift from
    microsoft.

    --
    [ Christopher Mason MPRC Bioinformatics http://proteomics ]
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: SPN Canonicalization

    Christopher Mason wrote:

    > Yeah, this is a messy, long-standing, and unresolved issue in kerberos.
    > In theory canonicalization introduces a potential MITM attack which
    > essentially undermines mutual authentication; in practice, everyone does
    > it. This is apparently to be addressed in future protocol mods, but
    > it's unclear what to do in software that actually needs to work today.
    > Read on for details. Maybe this could update the kerberos FAQ?


    MIT's Kerberos implementation through the 1.4.1 release does indeed use
    DNS to resolve the user entered host name and translate it to the
    reverse lookup name. The reason for doing this is that it was assumed
    at one point in time that

    (a) the DNS infrastructure and the Kerberos infrastructure would be
    controlled by the same entity
    (b) it is more important to simplify Kerberos so that fewer keys must be
    managed on a single machine

    The reality is that today (a) is frequently not true and in today's
    environment "simple" loses out to "secure".

    The MIT Kerberos team has already checked in changes to allow the
    DNS-based hostname transformation within the Kerberos libraries to be
    disabled.

    > I've done some googling on this issue and the clearest statement I can
    > yet find comes at the end of section 1.3 in RFC4120, which states:
    >
    >> 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).

    >
    > [...]
    >
    >> Implementation note: Many current implementations do some degree
    >> of canonicalization of the provided service name, often using DNS
    >> even though it creates security problems. However, there is no
    >> consistency among implementations as to whether the service name
    >> is case folded to lowercase or whether reverse resolution is
    >> used. To maximize interoperability and security, applications
    >> SHOULD provide security mechanisms with names that result from
    >> folding the user- entered name to lowercase without performing
    >> any other modifications or canonicalization.

    >
    >
    > Clear as mud? So it seems like we're left with a choice between
    > interoperability and correctness. Almost all other discussion I find of
    > this issue seem to indicate that canonicalization is performed in
    > practice. Firefox and IE definitely do it. See also question 2.14 in
    > the Kerberos FAQ:
    > ,
    > and numerous previous discussions on comp.protocols.kerberos such as
    > this thread on load balancing and kerberos:
    > .


    In the case of a cluster of machines providing services for a given
    service, without DNS-based hostname translation the keytab on a
    particular machine must contain both the unique machine-specific name as
    well as the name given to the cluster.

    host/cluster-machine-1.domain@REALM
    host/cluster.domain@REALM

    When DNS-based hostname translation is used, only the unique
    machine-specific name must have a key provided.

    > Samba seems to work around this problem by creating a skillion different
    > keytab entries like:
    >
    > 3 HTTP/proteomics.mayo.edu@MFAD.MFROOT.ORG
    > 3 HTTP/proteomics@MFAD.MFROOT.ORG
    > 3 HTTP/PROTEOMICS@MFAD.MFROOT.ORG
    > 3 HTTP/PROTEOMICS.mayo.edu@MFAD.MFROOT.ORG
    > 3 HTTP/proteomics.MFAD.MFROOT.ORG@MFAD.MFROOT.ORG
    > 3 HTTP/proteomics.mfad.mfroot.org@MFAD.MFROOT.ORG
    >
    > and many more besides these (with different salts?). See
    > .
    > There's an additional problem with samba, active directory validated
    > writes, and disjoint namespaces that I'll save for another time.


    Samba is working around a problem that is slightly different from the
    multi-homing discussion. Depending upon how the Microsoft Windows
    CIFS/SMB client determines the name for the file server, the case of the
    name will be different and whether or not it is a fully-qualified
    domain name will be different. For a Microsoft Windows server, it does
    not care what service name is used. The server does not contain a list
    of service principal names and host keys. Instead it has a password
    and will generate on the fly a key for the service principal name that
    is used by the client. This works well for Windows because Windows
    treats names in a case insensitive manner. All that matters is that
    the machine password can be used to generate a key that decrypts the
    service ticket.

    Samba uses Kerberos libraries that are case sensitive. Therefore, they
    must provide separate keytab entries for each of the expected service
    principals that a Windows client joined to a domain might provide.

    > It seems to my uneducated eye that really GSSAPI should be such that we
    > simply hand it "HTTP" along with the host name entered by the user and
    > it figures out the rest. Alas, it is not so. What to do is anyone's
    > guess.


    GSSAPI on the client side does do what it should. Given a
    "service@host" when using a Kerberos mechanism it will obtain a Kerberos
    service ticket and establish a connection to the service.

    The requirement to make this work is that the names entered by the user
    (or those constructed by lookup) must have service principal names in
    the KDB and the keytab files on the machines that are hosting the
    service must contain entries for all of the service principal names that
    might be provided.

    Jeffrey Altman



    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

+ Reply to Thread