Subject: hostbased service names (or not)

From: Martin Rex <[email-masked]>
Date: Wed, 26 Apr 2000 21:26:50 +0200 (MET DST)

Mike Eisler wrote:
>
> Martin Rex wrote:
> >
> > What Kerberos principal name is supposed to be used for nfs?
> > Your Email seems to suggest that a nfs/f.q.d.n principal is required
> > for that?
>
> Yes it is.
>
> Getting way off topic here, but one reason I opted for "nfs" and not "host" 
> was that NFS servers often operate in a kernel environment and not a 
> user level environment, and I wanted to accommodate implementations that
> might chose to keep the keytab information completely in the kernel. If
> "host" were used, and the same machine supported a telnet service and an
> nfs service, this would not be possible for such implementations.

I'm really glad to hear the NFSv4 will require support for a 
the abstract hostbased service "nfs@hostname".  Thanks Mike!

Using "host@hostname" would have been a Kerberos-solution and not
a portable GSS-API solution.  At the GSS-API level, there should be
a distinct service name for every application protocol, so that
it is possible to run the services with different credentials.
It is possible at the gssapi mechanism spec level to define that
particular services should be mapped to a common target principal,
or it can be an implementation issue to perform such a mapping,
perhaps based on local or central configuration data.

Jeffrey Altman wrote:
>
> There is no GSSAPI authentication method for "telnet".  But if there
> was it would use "host/f.q.d.n" since that is what the KERBEROS_V5
> AUTH method uses.

Ken Hornstein wrote:
> I agree, and _if_ we had a GSS-API authentication mechanism for telnet,
> I would say that the only target name that should be tried would be
> "[email-masked]".

I strongly object.  GSS-API is an abstraction, the "host" service principal
that kerberized applications traditionally share is Kerberos-specific.

It MUST be "telnet@hostname", and the application doesn't care whether
your kerberos implementation maps this into "host/f.q.d.n@SOME-REALM"
or "telnet/f.q.d.n@SOME-REALM".

Jeffrey Altman wrote:
>
> There is no mapping within the GSSAPI implementation from "ftp" to
> "host".  This is simply part of the specification for how GSSAPI
> is used with a specific application level protocol (such as FTP.)

Ken Hornstein wrote:
>
> I believe everyone would agree that you don't need to do any special
> mapping between GSS-API service names and Kerberos principals; whatever
> the protocol specifies as the service name will be the correct principal.
> Of course, some protocols may specify more than one service name (like
> ftp), but IMHO that's a protocol-specific issue.

I object again!  Every mechanism must do a mapping, and even Kerberos
performs one.  The current Kerberos practice seems to be to replace the
hostname part with the FQDN from a DNS lookup.  It would be just fine
if Kerberos defined a similar "canonicalization" for the service part
of a hostbased service name to allow sharing of service credentials,
just as it seems to be done with the "host" service principal.

If SPKM-based mechanisms that use X.509 certs would adopt hostbased
service names (which I still doubt), they would have to define
the mapping, and it would be more complex than replacing "@" with "/"
and tacking on a REALM.  Currently they expose the subject DN from
the certificate in its full beauty, so you have to deal with
"OU=", "L=", "O=", "C=" and a few other components.

The way how SPKM and similar gssapi mechanisms are shipped and used
today, it is impossible to algorithmically map a hostbased service
name into a complete subject DN.  The extra DN components for a
particular installation are influenced by the CAs policy and
the administrators gusto, and it varies considerably these days...

That's why I would appreciate strict service naming rules for
SPKM mechanisms, but personally, I think it is impossible to
fit them into a GSS-API v2 mechanism together with X.500 DNs,
because some of the necessary name transformations are impossible
(i.e. populating ACLs via gss_export_name()).

Greg Hudson wrote:
>
> Jeffrey Altman wrote:
> >
> > Martin Rex wrote:
> > > If Kerberos wants to share the host/f.q.d.n for several services,
> > > then it is up to the Kerberos GSS-API mechanism spec to define
> > > exactly how an when "[email-masked]", "[email-masked]", "[email-masked]",
> > > etc. are internally transformed into "host/f.q.d.n".
> >
> > Read my words:
> >
> >   Your GSSAPI mechanism is NOT to perform any transformations of the
> >   service name as specified by the application.
>
> On what authority do you say this?  It doesn't make sense for the
> application to be worrying about the service namespace of the
> mechanism, since the whole point of GSSAPI is to abstract away the
> details of the mechanisms.

Thanks Greg!  I finally don't seem to be alone with my opinion
that GSS-API is an abstraction and mechanism specs need to take
this abstraction back into the real world with a clear specification.

Jeffrey Altman wrote:
>
> Martin Rex wrote:
> >
> > This is exactly broken application behaviour to work around defects
> > in the Kerberos GSS-API spec.  Yuck!
>
> There are no defects in the GSS-API spec.  There are no mapping of
> service names in the GSS-API specification.  You are creating
> something that does not exist.

I realize that you are a die-hard Kerberos enthusiast.  However
you're trying to wag a dog by it's tail.  GSS-API is not simply
a neat Kerberos API, but Kerberos 5 is one particular out of many
existing GSS-API mechanism.

Every mechanism needs to define its name syntax and the transformations
of any generic nametypes to provide interoperability for the applications
at the API level.

Btw. every Kerberos 5 gssapi mechanism must transform
hostbased service names into Kerberos principal names, because
(1) they don't have a REALM and (2) the '@' characters would have to
be quoted to be permitted within the name.  rfc1964 is simply lacking
the specification how to perform the mapping from the abstract
hostbased service name into the Kerberos 5 mechanism specific
"Kerberos Principal Name".

rfc1964bis can either add the missing definition, or it can reference
another standard that contains the definition.  The current hints
in some Kerberos documents for sharing the "host/f.q.d.n@SOME-REALM"
service principal for serveral applications is something that might
impact the definition of such a mapping (e.g. a [service_principal]
section in krb5.conf).  Kerberos-specific issues of sharing
particular credentials are a mechanism-specific issue.  It MUST
be hidden from applications at the GSS-API level.

We run our application server farms with an SPKM-like gssapi mechanism
and share the server credentials across all the servers of a server farm.
This eases our administration.  As a result, our application can not
possibly use hostbased service names as the target name.

Thomas Owusu wrote:
>
> What about GSS_Canonicalize_name? Is that supposed to perform
> transformation from "service@fqdn" to "service/fqdn@realm" when
> the mech type is Kerberos?

It depends on the particular Kerberos implementation.  MIT Kerberos
seems to perform the transformation immediately during gss_import_name().
gss_canonicalize_name() will ultimately have to map any name into
the canonical mechanism specific name format for a generic gssapi mech.

Jeffrey Altman wrote:
>
> There are a lot of benefits associated by being able to specify
> either a global key for all services or individual keys for each
> service.  Obviously, it is an either/or situation.

There are a lot of benefits with being able to share service credentials
for a server farm/cluster.  Traditional Kerberos 5 cannot solve this
(replay cache problem).  SPKM gssapi mechanisms don't have this limitation.
Coincidentally, hostbased service names will not work for this scenario,
one of the reasons why I don't like them.

Ken Hornstein wrote:
>
> Martin Rex wrote:
> > It is inappropriate to specify for GSS-API enabled application protocols
> > to use the hostbased service name "host@hostname" as the target name,
> > because that is Kerberos-specific and doesn't meet the GSS-API abstraction.
>
> Okay, so is your complaint that "host@hostname" isn't registered with
> IANA?  That should be easy to fix.  I don't think the intent is that
> "host@hostname" is supposed to be Kerberos-specific.

Nope.  Registering "host" with IANA would be very bad and misleading.
The notion of "host" is a breach of the GSS-API abstraction level.

The desire of Kerberos (admins) to share a common credential and
reuse an existing service-key infrastructure for serveral services
on a host is a (Kerberos) mechanism issue and not a GSS-API issue.
On those grounds, my request for requiring a host-independent service
name to share server credentials over multiple hosts of a server farm
with SPKM would be just as valid as the requirement for hostbased service
names from all gssapi mechanisms.

Mike Eisler wrote:
>
> The other complaint might be that host@hostname isn't mentioned in RFC 2743
> (GSS-API).  But that's a minor issue. I've always assumed that host@hostname
> was not intended to be Kerberos specific and vaugely recall discussion on cat
> about this. The reason why I didn't use it for NFS is what I said before: that
> NFs servers oare usually kernel resident, and this might cause problems for
> implementations on hosts that support r*, telnet, ftp, and nfs simultaneusly.
> This wouldn't be a problem for the Solaris implementation of NFS, but  I try
> to to think of other operating environments.

"host" is Kerberos specific, because it ignores the application/service
that is acutally being requested and assumes that (1) there are shared
credentials and (2) there is an almighty "root" account.

Jeffrey Altman wrote:
>
> In the past I have argued against the implememtation of a GSSAPI 
> Telnet AUTH method on the grounds that it is not needed and the 
> extra overhead of wrapping GSS around other protocols within a
> Telnet AUTH negotiation is unwarranted.  But given the inability 
> of using the traditional KERBEROS_V5 authentication method with
> Windows 2000, perhaps it has become necessary to define such a 
> standard to head off the implementation of a KERBEROS_5 SSPI specific
> method; or the use of service names which we would disagree with.
> 
> Anyone have an opinion on this matter?

I don't know the details of kerberized telnet, but wasn't it
insecure in that it didn't provide integrity protection on the
datastream?

I think the real network overhead of GSS-API framing is not as bad
as some people make it sound.  Compare the overheads of 

     a) traditional password-based telnet over IPSEC
  or b) GSS-API protected telnet

I haven't checked, but I assume the overhead is roughly the same.

Ken Hornstein wrote:
>
> Are there a _lot_ of GSSAPI mechanisms that I'm simply not aware of?

Yes there are.  Besides DASS (rfc1507 -- maybe long dead), I have seen
SESAME (Bull), 3 independent SPKMs, 2 other public-key based mechs,
Keon Agent (SecurityDynamics), my own SAPNTLM mechanism (a gssapi wrapper
for Microsoft Win32 NTLM SSP), a proprietary mechanism of a Swiss Bank.

>
> The GSSAPI mechanisms that I know about are:
>
> - Kerberos 5
> - DCE
> - SPKM
> - LIPKEY
>
> I know that Kerberos 5, DCE, and LIPKEY all support hostbased service
> names.

W2K Kerberos doesn't support GSS-API service names at the API.
That's why I want to add it into my GSS-API wrapper to the W2K Kerberos SSP.
However rfc1964 fails specify how this is to be done, and some
people participating in this discussion have apparently not
realized that this area is heavily underspecified.

Microsoft seems to have implemented a different service name model.
They probably encountered similar problems as all others that try
to operate in a truely distributed environment.

Even DCE realized that hostbased service names don't scale and
invented abstract service names.  Because of the underlying Kerberos
protocol, the abstract service names still get translated into
host-specific service principals internally.  Could someone please
verify whether DCE really supports the hostbased service nametype
at the API level?  Since the name-based Kerberos authentication
is still available from DCE, this could be possible, but it
is *NOT* implicit.

There is another Kerberos-derived GSS-API mechanism called "SESAME".
Last time I saw it, it didn't return the nametype OID for hostbased
service names from gss_inquire_names_for_mech().  I assume they
have more generic (i.e. hostindependent) service names.

Keon Agent doesn't return the OID for hostbased service names
from gss_inquire_names_for_mech() either.

Face it, hostbased service names are Kerberos-specific.  :)

Ken Hornstein wrote:
>
>          I'm not sure about SPKM (but the spec says it's designed to
> be as compatible with Kerberos as it can, so I would guess that it
> would support host-based serivce names).

I'm afraid to tell you the bad news.  Nope, none of 3 independent SPKM
implementations I've seen and neither of the two other public key based
mechanisms support hostbased service names.  The simple problem is that
nobody knows how to map between hostbased service names and X.500 DNs.

Names at GSS-API require several features.  Think not only of how to
compare only one or both elements of a hostbased service name with
parts of a X.500 DN in a similar stupid way how Web-Browsers
match their URLs against a server certificate.
There is gss_canonicalize_name() and gss_export_name() which must
be able to populate an ACL.

>
> Meta-observation: most of the code I'm aware of today that uses GSSAPI
> is using it as a way to provide Kerberos authentication to protocols &
> applications, and all of it is written to use host-based service
> names.  If they're truely "not portable" (and I believe the consenses
> is that _are_ supposed to be portable) then any mechanism that doesn't
> implement host-based service names is going to be for an unpleasant
> surprise, to say the least.

The only way for applications to portably support arbitrary gssapi
mechanisms is to provide a means for the user and/or administrator
to pass an opaque target name to the gssapi mechanism.

From the past discussion I read that this is even required for
Kerberos, since people cannot make up their minds which services
share which keys -- and a connect/fail/connect-again is not
an acceptable solution.

Maybe it never occured to you that you had to audit every
single failed logon and needed to make sure that not a single one
was an attempted break-in.  You absolutely don't want applications
that trial-and-error a list of target names, besides of the wasted
resources.

What scares me as a result from this discussion is how many people
don't really care about really authenticating a target.  Every single one
that uses hostbased service names which are canonicalized via
traditional DNS is guilty of not doing target authentication.
99.999% of HTTPS is done without target authentication.

The reason why kerberized application are providing the
target name is because they need to know for which service to
request a ticket -- even if they actually don't care.
Even the GSS-API spec unconditionally required a target name
for gss_init_sec_context(), but it was finally relaxed before
we finalized rfc2743.

When the client doesn't care about the target's identity,
it should not be required to provide a target name.  It would be
quite possible to write a Kerberos-based gssapi mechanism spec
that would allow this:  the first token exchange would simply
request the service name from the target, the second round
would perform the regular AP_REQ/AP_REP.

Or even further: Don't use an a-priori target name for mutual
authentication similar to what TLS does.  Mutually prove your
identities and decide after the "identity verification"
whether you want to talk to this server or not.
However there are some implicit requirements in the gss_*_name()
calls of GSS-API v2 that limit the flexibility of what a GSS-API
mechanism might support in this area.

-Martin
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 26 Apr 2000 16:09:35 -0500

They way I see it, the telnet, rsh and rlogin protocols all get you
the same service, from a security point of view.  They all let you
run commands on the machine; they just wrap the presentation
differently.  NFS and ftp give you different services from the
above.  But if POP and IMAP were just a little less different, I'd
consider them to be the same service in a different protocol wrapping
also.

> [...]

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Apr 2000 08:39:28 +0200 (METDST)

> consider them to be the same service in a different protocol wrapping

If your only tool is a hammer, everything looks just like a nail..

The GSS-API abstraction will classify "telnet", "rsh" and "rlogin"
as individual and distinct applications and provide independent
hostbased service names for each of them.  This is the abstraction
level of GSS-API.

On all C2-level or less Unix systems these services offer the same
level of access and are run with the same privileges.  It would
be ok to share the gssapi service credentials for these services
provided that the employed gssapi mechanism supports this sharing.

It is tradition with Kerberos to share these credentials and
therefore it would be a sensible action to expand the Kerberos
gssapi mechanism and define a mapping of the "telnet", "rlogin"
and "rsh" services to the same "host" service principal.
AGAIN, this is not an application issue and not a GSS-API issue!!!
(I will bring a clue-x-4 to the Pittsburgh IETF meeting...)

It might not be obvious for you, but it would be quite possible
to have a gssapi mechanism that uses credentials on a SmartCard
and does not allow multi-process access to this credential, so
that sharing of the credential, even for applications providing
the same level of access is not possible.  This is well within
the spec of GSS-API, and applications must not discriminate
such a GSS-API mechanism by assuming shared credentials for
any independent applications.

-Martin