Subject: Re: Soliciting additional GSS/Kerberos interoperability results

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 20:44:14 +0200 (METDST)

John Brezak wrote:
> 
> Consider this scenario. Clients connect to a computer that is known by
> multiple DNS name. As a result it has these Kerberos principals -
> host/foo.dns.com, host/bar.dns.com, host/baz.xyz.com. This host is the
> middle tier of an application and needs to access a database on another
> server. That server authenticates the middle tier server and needs to
> have it's identity on the database access control lists. In order for
> this to work, all 3 principal names would have to be on the ACLs, but
> there is no canonical name for the host. What is the expected behavior
> of gss_canonicalize_name when presented with these principals for the
> same application?

That is what canonical names is about.

The middle-tier hosts should never behave schizophrenic.
When a service is the initiator of a connection, it should use
exactly one identity (except under delegation), and for that identity
there is a canonical representation.

Take a multihomed host today.  It has only a single hostname,
no matter many network interfaces the machine uses, which IP-Addresses are
assigned to these interfaces (there may even be several IP-Addresses
assigned per interface) and what DNS-names map to the IP-Addresses
assigned to those interfaces.

Now there is the tradition in Kerberos of *not* performing a mutual
authentication of the server, and the only reason why the clients
supply a hostbased service name derived from the TCP transport endpoint
as target is for the optimized authentication exchange.  If they
really cared about authentication, they would have never used
DNS for "canonicalization" of the hostname part of a hostbased
service name, NEVER.  I think they're still doing it.  Hostbased
service names are a Kerberos specialty (I should better say "myth"),

The TCP-endpoint derived identity doesn't work very well for
Kerberos and multihomed hosts (the IP-Address restriction of tickets
probably causes all sorts of problems with multihomes hosts as well),
and the large majority of GSS-API mechanisms doesn't even understand
hostbased service names at all.

In the GSS-API world the identity of a communication peer and
the transport endpoint address under which it can be reached
are two seperate pieces of information.  Deriving an identity
from a transport endpoint is not only an insecure and bad idea,
it will simply not work with most gssapi mechanisms and is
therefore extremely non-portable.

One thing that does not yet exist and may be pretty useful is
an API extension to GSS-API that permits to lookup the transport
address for a generic service.  I think I mentioned this several
times already: DCE offers such a service.  And such a service
doesn't even need to be secure!  The mutual authentication will
make sure that you detect spoofed answers.  In case you want to
share a single credential (identity) among multiple services,
you will probably have to provide a secure naming service as well
that can provide secure name canonicalization.
(we had this discussion already, didn't we?)

-Martin

> 
> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Friday, May 11, 2001 2:58 AM
> To: John Brezak
> Subject: Re: Soliciting additional GSS/Kerberos interoperability results
> 
> 
> John Brezak wrote:
> > 
> > There appears to be an issue with gss_canonicalize_name when used with
> 
> > Kerberos. If a middle tier server has multiple principals (as is 
> > currently the case with Kerberos), how can gss_canonicalize name be 
> > used in its described way for building a canonical name for that 
> > middle-tier server that can be stored on ACLs?
> 
> Which particular problem are you referring to?
> (MIT) Kerberos 5 doesn't have a problem here, it should be implementable
> with DCE.  I know that Microsoft Kerberos has a problem, but that's a
> design flaw.
> 
> We have certified more about a dozen different gssapi mechanisms for
> interoperability with our application and none of them had a problem
> with gss_canonicalize_name() ...
> 
> -Martin
>

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 21:17:47 +0200 (METDST)

Ken Hornstein wrote:
> To be fair, Martin ... one thing you've always ignored in this discussion
> is that all IETF protocols that use GSSAPI require the use of host-based
> service names.  So I'm not sure it's reasonable in the context of IETF
> protocols to take the position that host-based service names shouldn't
> be used.  If you want to go back and tell all of those GSSAPI consumers
> that they've been doing it wrong, fair enough ... but I almost think it's
> too late for that.

What I'm telling them is they will not be portable to any gssapi
mechanism beyond Kerberos, that's all.  When we adopted GSS-API,
we did it to remain portable across gssapi mechanism, because we
didn't ship a mechanism and for years relied completely on third
party suppliers.  It worked out pretty well.  

Although I certainly wouldn't call it first choice, our customers
can use Microsoft's NTLM authentication mechanism for Single Sign-On
with our application, and some of them do.

There are several PKI-based gssapi mechanisms and a few with a
complex proprietary architecture.  Only Kerberos accepts hostbased
service names.  Look at RSA's Keon Agent: although it's names syntax
looks very much like hostbased service names, the two nametype oids
for hostbased service names are rejected with GSS_S_BAD_NAMETYPE...

> 
> (And speaking as someone who has successfully done Kerberos authentication
> in nearly every contortion imaginable with multihomed hosts, I never
> really had that many problems with it).

How do you control placing of IP-Address restrictions in forwarded TGTs
for multihomed hosts?  Is there a standard how this is done?

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 May 2001 15:22:11 -0400

>for multihomed hosts?  Is there a standard how this is done?

The multihomed host has multiple A records, and all of the A records
associated with a host are placed into the forwarded ticket.  The security
is dubious, but then again so is the security of IP addesses in Kerberos
tickets anyway :-/

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 May 2001 14:59:59 -0400

--Ken

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 15:39:27 -0400

Host-based principal names aren't really so necessary -- if anything
they just create two different namespaces: one for users, one for
services, but since most everyone uses fully qualified hostnames for
service principals nowadays that doesn't really matter... :^/

In fact, doesn't MS AD by default not use host-based principals? You can
create host-based principal name mappings for host accounts in AD
though.

Also, isn't it gss_import_name()'s job to determine the acceptor's
mechanism specific names? and if the mechanism doesn't have a host-based
naming concept, can't it just ignore the host-based name type (on the
theory that host-based naming is merely a namespace partition which need
not exist)?

Nico

--

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 23:41:59 +0200 (METDST)

> that they've been doing it wrong, fair enough ... but I almost think it's

I don't know how many IETF protocols exist by now who make the 
obviously unwarranted assumption that hostbased services names
are available.  I know about an FTP-extension and NFSv4, and I
heavily objected to making it a requirement in NFSv4.

Look at the GSS-API spec.  GSS-API v1 (rfc1508) doesn't know them
at all and GSS-API v2 (rfc2743) doesn't promise the availability
of any of the nametypes mentioned in section 4.  It is simply
a list of conceivable nametypes and if a mechanism supports
them, that is how they should do it.

Actually, the only nametype in rfc2743 that an application can
expect from a GSS-API v2 gssapi mechanism is the exported name type.
This is not a printable nametype however and for portability,
this is a sort-of hen-and-egg problem.  Therefore I wanted to
require mechanisms to additonally support a nametype=NULL for
gss_import_name() to mean the mechanisms native nametype.

All the time that I have been involved with GSS-API, I was asking
for more rules on names and naming.  I was constantly denied this
request (and for good).   Requiring from a gssapi mechanism
to be able to map a hostbased name into its native namespace
would be a full turn on that position.

"If your only tool is a hammer, everything looks like a nail to you."
The people who wrote application protocols and require hostbased
service names apparently never took the time to really look at
GSS-API and different implementations.  They looked at Kerberos
and made *really* bad assumptions.

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 May 2001 17:47:53 -0400

>heavily objected to making it a requirement in NFSv4.

All the ones that specify SASL do so as well (my reading of the SASL
spec is that it requires hostbased service names).

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 11 May 2001 17:51:33 -0400

>and made *really* bad assumptions.

I know you deal with a lot of GSSAPI implementations ... but they don't
seem to be available to anyone else.  I admit I'm not a GSSAPI nut like
you, but the ones I know about are Kerberos 5, DCE, and LIPKEY.  I have
no doubt these other GSSAPI implementations are out there ... but how
come the developers of them aren't at the IETF complaining about
hostbased service names?  Do they not care about working in IETF protocols?

--Ken

---

From: Martin Rex <[email-masked]>
Date: Sat, 12 May 2001 00:51:14 +0200 (METDST)

Ken Hornstein wrote:
> you, but the ones I know about are Kerberos 5, DCE, and LIPKEY.

Kerberos 5, DCE and SESAME are all Kerberos when it comes to
hostbased names.  Entrust's SPKM implementation has been available
for quite a while, although it's neither free nor opensource...

Microsoft's NTLM doesn't know hostbased service names, but as it
doesn't support mutual authentication, it doesn't really count.

Whether or not hostbased service names can be supported depends
on the native namespace of a gssapi mechanism.  Kerberos 5, DCE
and SESAME all use the Kerberos namespace therefore I don't
really distinguish them here.

PKI-based mechanism (like SPKM) often use the Subject DN of
X.509 certificates as their namespace, and most don't have
a "central user database".  As soon as you go PKI
and allow the users to use multiple CAs you have a serious
problem how to deal with hostbased service names.  So implementors
usually don't implement them.

e.g.:
   user1:    CN=user1, O=companyA, C=US
   user2:    CN=user2, O=companyB, C=DE

  now how would you map ftp@somehost into an distinguished name?

  possibilities:

             EA=ftp@somehost, O=companyA, C=US
	     EA=ftp@somehost, O=companyB, C=DE

  now there is the problem that for one host this should reliably
  work and for the other this should reliably fail and there must
  not be any ambiguity (since we want to perform *MUTUAL* authentication).

  pick one.
 
  wrong one.

X.500 DNs are a major pain, I know.  Most implementations that
I've seen even distinguish "CN=user1, C=US" from "C=US, CN=user1"
and although this could theoretically be improved, there is no
chance to canonicalize "CN=user1, OU=A, OU=B, O=C, CN=US"
vs. "CN=user1, OU=B, OU=A, O=C, CN=US".

>                                                                 I have

Some do, some don't, most I don't know.

There is a list at
http://www.sap.com./solutions/compsoft/cspdirectory/products/certify/secunet.asp?DescID=129&ProdDesc=Network+Security

There are two Kerberos 5 implementations:
 - Cybersafe's TrustBroker 
 - eTrust Single Sign-On from Computer Associates
   which is former Platinum former Veritas former OpenVision

These are mechanisms with X.500 DNs:
Entrust, Shym and UniSecurity have SPKM(1), SECUDE is similar to SPKM1,
NEC and Deutsche Telekom have a proprietary PKI-based mechanism

RSA and iT_Security provide proprietary gssapi mechanisms that
apparently use a user@host syntax for services AND users.
(RSA's Keon Agent definitely rejects the hostbased service name
 nametype OID.)

Other than that
there is MIT Kerberos, Microsoft Kerberos and Heimdal(Sweden),
DCE is somewhere, SESAME is available from Bull(France), SSE(Ireland)
(what happened to ICL(UK)?)

I don't know whether Baltimore ships their SPKM1 implementation,
Safelayer(Spain) working on an SSL gssapi mechanism and
Sagem(France) has also a PKI-based gssapi mechanism in the works.

I provide a gssapi v2 compliant wrapper for Microsoft's NTLM SSP.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 May 2001 10:52:06 -0400

On Sat, May 12, 2001 at 12:51:14AM +0200, Martin Rex wrote:

[...]

> 	     EA=ftp@somehost, O=companyB, C=DE

Wait a minute. Kerberos has the *same* problem.

Is it ftp/somehost@REALM_A ot ftp/somehost@REALM_B??

There's two ways this problem has been solved in the past: a) DNS
domain->realm mapping rules specified in the clients' configuration
and/or b) domain->realm and host->realm mapping records in the address
resolution protocol (i.e., a TXT DNS RR convention).

I don't see why implementors of GSS PKI mechanisms can't do the same
sort of thing.

So host-based  service names are not just a a namespace separator as I
thought before, but rather they are a hint to GSS-API about how to
canonicalize the name.

>   not be any ambiguity (since we want to perform *MUTUAL* authentication).

Well then. This is a problem. Either the user knows the full name (*) or
the mechanism by which the service's realm is determined is secure.

(*) From an UI point of view the app should confirm the canonical
service name with the user after any name canonicalization but before
proceeding (possibly after context setup, but certainly before
exchanging data).

[...]

> -Martin

Cheers,

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 14 May 2001 12:16:39 -0400

>Not necessarily.  In those Kerberos installations where such a problem
>exists, secure *mutual* authentication may be impossible.

I think the actual reality is a lot more complex; the attacks that have
been described against Kerberos using DNS canonicalization games are
only workable in some circumstances.  I think everyone should understand
the risks, but I can think of a number of cases where a site might decide
that the risks are worth the gains.  In my mind, all security has to be
balanced against usability; where you draw that line is, of course, up
to you.

>Using DNS for transformations on the authentication target is where
>you loose security.  Even where secure DNS is available, it would be
>a bad idea to make DNS it part of the authentication infrastructure,
>since it is usually managed by the network operations people and
>not by the user admin people.

I can't agree with this; this information is relatively static and only
needs to be configured once.

>across redundant KDCs is not regarded a problem).  Although they
>are ok for traditional hostbased services, they are a usability
>problem for distributed or replicated services.

Oh, balderdash!  I've written a distributed service using raw Kerberos,
and it was _not_ a problem.  It just requires proper design.

--Ken

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 May 2001 18:03:52 +0200 (METDST)

> Is it ftp/somehost@REALM_A ot ftp/somehost@REALM_B??

In MIT Kerberos v1.0 this was defined in krb5.conf/krb5.ini

> I don't see why implementors of GSS PKI mechanisms can't do the same

How?  What is a PKI?  It is something extremely undefined!
The only thing that you are very like to find in a PKI are
X.509 certs and at least one CA.  Everything else is optional:
Certification paths, multiple trusted CAs, cross-certified paths,
directories, CRLs, and whether any of that is online available
or strictly offline...

> thought before, but rather they are a hint to GSS-API about how to

Hostbased service names are names from a very particular and
very architecture-specific namespace.  GSS-API is not tied to TCP/IP
or any other transport protocol.  GSS-API doesn't have any problems
with (multiple) firewall or proxy traversal, whereas Kerberos has
serious problems with firewalls.  Kerberos is heavily tied into the
transport protocol, and that is is a clear disadvantage.

The primary reason for the existance of hostbased service names
in Kerberos is that sharing of credentials accross hosts would
allow replay attacks with the authenticator-based authentication.
So for every host a seperate (set of) principal(s)/credential(s)
is required, even for multiple instances of the same distributed
service (the KDC seems to be the only service where replay protection
across redundant KDCs is not regarded a problem).  Although they
are ok for traditional hostbased services, they are a usability
problem for distributed or replicated services.  Just imagine
when TGS had to use a hostbased service name ...

> the mechanism by which the service's realm is determined is secure.

The Realm-mapping via krb5.conf/krb5.ini is "secure".  Canonicalization
of the hostname part of a hostbased service name via DNS, as currently
done by MIT Kerberos is *not* secure.

> proceeding (possibly after context setup, but certainly before

You mean you want to involve the user in verifying and confirming
an insecure canonicalization?  Are you serious?

It's like Microsoft who is suggesting that users, when prompted for an
ActiveX issued to Microsoft Corporation signed by VersSign should open
the Certificate Properties dialogue where they can easily recognize
from the issuing date of the certificate, when it is January 30th,2001
or January 31th,2001 that this is "not a bona fide Microsoft Authenticode
Certificate"?

I'm sorry, but this is bound to loose.

And those few users that would be able to verify and confirm an
insecure canonicalization and really care about authentication,
why would they ever start with a non-canonical name?

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 May 2001 12:29:39 -0400

> exists, secure *mutual* authentication may be impossible.

Yes, I agree. The point was that any multi-realm system where hostname->
realm or service->host/realm mappings are not obvious has this problem.

> In MIT Kerberos v1.0 this was defined in krb5.conf/krb5.ini

Yes. That's what I said (see (a) below).

> you loose security.

Indeed.

>                      Even where secure DNS is available, it would be

Well, if it's so hard to define PKI, then let's not bother with this
thread... :) :)

> allow replay attacks with the authenticator-based authentication.

Not only that. Each host is a different entity. Replay attacks across
hosts sharing the same Kerberos principal wouldn't be hard if the
address the initiator is connecting to is referenced in the
Kerberos authenticator. But that's another story.

> when TGS had to use a hostbased service name ...

Yes, this is problematic. But the problem could be fixed -- see above.

Actually, is that something worth adding to the rfc1510 revisions? An
optional HostAddress item in the Authenticator sequence to indicate
which address of the remote host the client is connecting to? The idea
would be that, if the service principal's key is shared over multiple
hosts, then the service should (MUST) check that this HostAddress match
the destination address of the client's request.

> The Realm-mapping via krb5.conf/krb5.ini is "secure".  Canonicalization

Right. So PKI GSS mech vendors could add that feature -- of course, in a
large Internet, that becomes unworkable and the only alternative is a
generic domain->realm convention or mapping via DNS (which is not
secure, so it's not really an option).

> an insecure canonicalization?  Are you serious?

Heh, well, it's an accepted practice in this industry, no? :) :)

Yes, dialog-based security is not really security, sigh.

> or January 31th,2001 that this is "not a bona fide Microsoft Authenticode

Heh.

> I'm sorry, but this is bound to loose.

Yes.

> why would they ever start with a non-canonical name?

Ultimately this is the problem -- we can't carry a phone book in our
heads, so we need lookup services, and they have to be secure -- but we
have no such secure lookup services, not Internet-wide anyways, not
yet.

Cheers,

Nico
--