Subject: Re: hostbased service names (or not)

From: Jeffrey Altman <[email-masked]>
Date: Wed, 26 Apr 2000 17:23:52 EDT

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

Every mechanism does a format mapping.  The mechansim MUST NOT change
the data the application passes to the mechanism.
 
> 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.

Exactly.  The mechanism is not allowed to change the value of the
data.  All it can do is change the format of the data to ensure that
the format is compatible with the GSSAPI exchange.

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

Funny, I seem to support quite a wide range of authentication methods:

 . X.509 certificates
 . Kerberos
 . SRP
 . S/Key

I use them all...

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

Interoperability 'yes'.  Tampering with the requested credentials 'no'.
 
> 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?

Privacy and integrity protection can be provided for telnet via TLS.
The old telnet encryption option (which has nothing to do with a
particular authentication option) does not provide integrity
protection.  That is why it is being replaced by TLS.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Martin Rex <[email-masked]>
Date: Thu, 27 Apr 2000 08:23:11 +0200 (METDST)

> the data the application passes to the mechanism.

This discussion is going round in circles.

You apparently ignore completely what the GSS-API spec explicitly
recommends and the abstraction model behind GSS-API.
You also ignore what Kerberos will have to do and what each and
every existing Kerberos gssapi mechanism actually does.

Take MIT's Kerberos (at least this was the behaviour for beta6 -> v1.0.5):
Pass in a hostbased service name via gss_import_name() and print
the resulting name via gss_display_name().  You will realize that
it was mapped into a Kerberos principal name, i.e. the '@' was
replaced by a '/', the hostname part was canonicalized via DNS,
and a REALM was appended.  Whether the resulting service principal
is "service/f.q.d.n@REALM-A" or "service/f.q.d.n@REALM-B" is beyond
the control of the application as long as it sticks to hostbased
service names.  In MIT Kerberos, the [domain_realm] section of krb5.conf
will be checked with the domain name of the canonicalized host to
figure out in which REALM the host(based service) resides.

> the format is compatible with the GSSAPI exchange.

I'm sorry, but this is BS.

Which part of the GSS-API spec is so misleading that it causes this
confusion for you -- maybe we need to fix it?  There is absolutely
no requirement for GSS-API mechanisms that the target ever gets to
know which target name the initiator has used or wants to authenticate.

For the abstract GSS-API, the target name is only required as a
reference value when doing target authentication.  However there is
a historical shortcoming in the Kerberos GSS-API mechanism that
requires the presence of a target name even for unilateral authentication
of the initiator by the acceptor.

There is another misconception that you seem to have.
The original purpose of authentication in GSS-API and in many applications
is not to simply distinguish sessions, but to be able to recognize
principals each and every time that they authenticate.  Normally this is
done with some sort of mapping table that contains the name of
the principal and a (locally) unique key (UID,SID,UUID), under which
authorization data and user profile information is keyed.  Usually the
intermediate unique key is only need to adapt to the access control
list (ACL) structure of an underlying TCB.  If authorization is handled
completely within the application, the application ACL may directly
contain the (externally) authenticated identities.

There were some functions added to Version 2 of GSS-API which will
enable ACL maintenance for applications.  The requirement is, that
every valid name can be canonicalized and be used to populate a
binary ACL before the referenced identity even authenticates for
the first time to this application.  If an application imports
"service@host" with a Kerberos GSS-API mechanism and puts it into
its ACL, it will be remembered as "service/f.q.d.n@REALMA".  Now
when the [domain_realm] part of krb5.conf is changed, or when
the "host" entry in DNS is made a CNAME referencing a different host,
then "service@host" may suddenly resolve to "service/f.q.d.n@REALMB".
This change will go unnoticed by the target name to gss_init_sec_context(),
but it will certainly show when the application receives a request
from said service and no longer find a matching ACL entry.

In a truely distributed environment there are no distinct users and
services, everything takes every role and authentications are performed
in both directions alike.  Just as Kerberos does not require hostbased
users, it should not require hostbased services.  The reason why it does
is the replay cache problem with the authenticators.  This makes me
wonder: is there any protection of users against replay of service
tickets from the KDC?

> Funny, I seem to support quite a wide range of authentication methods:

Wow - Great!  You seem to be a mighty wizard.

Please share the wisdom with us how to map between hostbased service names
and X.509 certificates, because none of us has been able to come up
with a solution so far.

> Interoperability 'yes'.  Tampering with the requested credentials 'no'.

Tampering with credentials?  You're taking the GSS-API spec backwards
again.  An application can not supply credentials to a gssapi mechanism
via the regular GSS-API (ignoring Ted's proposed interactive query here). 

Did you realize that for GSS-API v1 it was not even required that
a process could acquire credentials by name (only default credentials
were required -- despite the fact that default Kerberos acceptor
credentials are underspecified!).  It took me a while to convince
people that support for requesting credentials by name should be
in the base spec.  

-Martin

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 27 Apr 2000 15:08:23 -0400

>recommends and the abstraction model behind GSS-API.

This I believe is part of the problem.

I think that very few people truely understand GSSAPI.  I certainly
don't think that I do.  But I have at least read some of the
GSSAPI RFC's, and I don't believe I know what you're referring to
when you say "what the GSS-API spec explicitly recommends", and
I _certainly_ don't understand the abstraction model; it's never
clearly explained (IMHO).  I mean yes, I understand that GSS-API
is supposed to abstract out the details of the way the security
mechanism works, but I don't agree that the use of "host" as a service
name violates any fundamental abstraction that _I've_ read about.
I'd welcome corrections, of course.

Some observations about this whole discussion:

- Martin, you are the _only_ person arguing that host-based service
  names are not portable.  Everyone else disagrees with you, and I'm
  not talking about nutballs like me; both Cliff Newmann and John Linn
  (who's name is actually _on_ the GSS-API spec) say that the
  host-based service names have always been intended to be mechanism
  independent.  The specification also disagrees with you; section 4.1
  of RFC 2743 says "Support for this name form is recommended to
  mechanism designers _in the interests of portability_, but is not
  mandated by this specification".  In my mind, that is rather
  unambiguously saying that host-based service names are intended
  to be portable.

- The arguments you make about "host" being shared among services also
  apply to the IANA registered service for "rcmd", do they not?  But I
  see that "host" has already been specified in RFC 2743, _and_ in fact
  the whole service name sharing concept (again, from section 4.1).

   Documents specifying means for GSS integration into a particular
   protocol should state either:

      (a) that a specific IANA-registered name associated with that
      protocol shall be used for the "service" element (this admits, if
      needed, the possibility that a single name can be registered and
      shared among a related set of protocols), or

      (b) that the generic name "host" shall be used for the "service"
      element, or

      (c) that, for that protocol, fallback in specified order (a, then
      b) or (b, then a) shall be applied.

  It seems to me that what RFC 2228 describes for GSSAPI and FTP is
  perfectly allowable in light of RFC 2743, and in fact sharing "host"
  among telnet/rlogin/rsh is perfectly fine.

- I have not been able to find an example of an IETF protocol that uses
  GSSAPI and _doesn't_ use host-based service names.  If we really
  shouldn't be using them as portable names, us folks in CAT have
  really screwed up in telling the rest of IETF "this is how you use
  GSSAPI in your protocol".

- While the whole discussion about associating services with hosts
  versus abstract service names probably should be a seperate thread, I
  feel I must point out that one of the drawbacks to doing this is a
  lowering of security (because if one machine is compromised, all
  machines that use this service will be compromised).  Also, you
  _could_ have designed a application protocol that used host-based
  service names (it didn't even have to use DNS for the host
  identification part); certainly the use of distributed services
  doesn't preclude the use of host-specific names.

- Your objections to the use of Secure DNS to secure the canonicalization
  of hostnames seems to be mostly political rather than technical.

>wonder: is there any protection of users against replay of service

There isn't, actually, but this in particular isn't a problem, because
you still need the TGT session key to unlock the reply from the KDC
(and if you have _that_, you already know enough to make a legitimate
service ticket request).

--Ken

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Apr 2000 15:39:43 +0200 (METDST)

> I'd welcome corrections, of course.

The notion that two independent applications *must* be able to share
an identity (and therefore a credential) is an obvious breach of the
GSS-API abstraction.

After Ted's hint about what else is written in section 4.1 of rfc2743,
I realize that this section is breaching the GSS-API abstraction itself,
because it suggest to make assumptions that every gssapi mechanism
in the world and of the future can be assumed to look like the
Kerberos of today.

- I think the idea of sharing a single generic name for applications
  is invalid at the GSS-API level.  It is very valid and useful to
  allow sharing of identities (=credentials) at the mechanism level,
  provided that the mechanism is capable of doing that.

>   independent.

Maybe I'm the only one that uses gssapi mechanisms that don't support
hostbased service names.

Facts are:

   - there are several gssapi mechanisms that do not support
     the GSS_C_NT_HOSTBASED_SERVICE oid.  None of the public
     key based mechanisms (SPKM and related) has it.
     Maybe its a simple bug that SecurityDynamics KeonAgent doesn't
     return the OID in the set from gss_inquire_names_for_mech().

   - Only the Kerberos gssapi mechanism defines a mechanism specific
     nametype "Kerberos principal name".  (btw. rfc1964bis should address
     UTF8 names and their encoding)

   - SPKM and LIPKEY lack the definition of a mechanism specific
     nametype.
     For SPKM this has caused all independent implementations to
     create non-interoperable nametypes (I've seen 5 independent
     mechanisms so far).  I have no reason to believe that LIPKEY
     will improve the situation.  I strongly encourage the
     document authors to propose a mechanism specific nametype,
     discuss it here and nail it down.  Since existing implementations
     are non-interoperable, we can only make things better.

   - None of the available mechanism specification properly defines
     a mapping between the generic nametypes at the gssapi level
     and the mechanism specific nametype of the mechanism.

     Because of the simple structure of Kerberos principal names
     and the codesharing tradition among Kerberos implementors,
     we do have interoperable name mappings in most implementations.

     However I still see battles on Kerberos naming in various places:
     the case of the realm name, the determination of a realm for
     a particular host (this directly affects the implementation
     of hostbased service names), and the mapping of service names
     that Microsoft has implemented.  This is a clear indicator that
     Kerberos names were underspecified in previous specs.

     I want to add an interoperable hostbased service name implementation
     to my GSS-API v2 wrapper to the W2K Kerberos SSP, that's why I
     have been asking for the exact spec -- rfc1964 is incomplete.

>
>                 The specification also disagrees with you; section 4.1

They are intended to be portable, and they may even be the most portable
nametype that is currently contained in rfc2743.  Fact is, they are
not portable, because non-Kerberos mechanisms haven't defined a mapping
and as a result not implemented them.

If the LIPKEY spec is not updated to specify how to perform the
authentication of an X.509-based server identity with the hostbased
service name it will be guaranteed to result in non-interoperable
API implementations.  Interoperability on the wire is not enough,
GSS-API is an API!

To me, it sounded like Mike has a LIPKEY implementation.  At least
he should publish how it implements the authentication and maybe
we can refine the example into a requirement for the spec to
allow interoperable independent implementations to happen.

>   among telnet/rlogin/rsh is perfectly fine.

It is *broken* to specify procedures that will cause authentication
failures.  rfc2228 has exactly this potential.  One may find fail-back
modes ok for human interactions, but for services talking to other
services the overhead of resource-wasting fail-backs must be avoided.

Authentication failures may be particularly annoying, because they
fill up audit logs and may set off alarms.  And frequent false alarms
will significantly drain attention from real alarms.

>   GSSAPI in your protocol".

Because they don't know better.  Some of the application developers
may have Kerberos experience, and some may have even tried with the
Kerberos gssapi mechanism and some may have even read rfc2078/2743
and bought into section 4.1. vision of a portable hostbased service name.

SPKM and related gssapi mechanisms and a few others are only available
for $$$, if at all, and they take a considerable effort for installation
and creation of credentials, that's probably the reason why none of
the apps guys has ever tried any of them.

I think we should write a BCP for GSS-API use and the common pitfalls,
like the assumption that hostbased service names are available and
portable accross (non-Kerberos) gssapi mechanisms.

>   doesn't preclude the use of host-specific names.

Yes, host-independent service names and their resolution into a pair
of (target name, transport endpoint) should be a seperate thread.

We didn't write our own gssapi mechanism, we bought one.
And it does *not* implement hostbased service names, just like every
other SPKM and related gssapi mechanism with X.509 certs that I have seen.

>   of hostnames seems to be mostly political rather than technical.

Not completely.  There is a technical issue in that the registration
of DNS domains as well as the assignment of hostnames within organizations
is (a) insecure, (b) performed on a first-come first-serve basis
and (c) unreliable because of ownership transfer over (trademark) disputes.

I haven't looked at any of the Secure DNS specs, but I'm convinced that
it causes plenty of security illusions with a lot of people.  I doubt
that it will be possible for anyone to come up with a secure trustmodel
for secure DNS that is still manageable.  Blind trust in a single root
will open myriads of tiny security vulnerabilities, and attackers
will figure out ways to widen one or the other to an actual hole whenever
they need it.

> (and if you have _that_, you already know enough to make a legitimate

I didn't say that I want to look inside the ticket.

I just remembered that Ted once told me the key for a service ticket
was used to seed the generation of session keys on the assumption
it is "fresh and hasn't been used before".  I know to little about
how and where entropy is gathered in Kerberos, and I was wondering
about the motivation of key derivation discussion.

-Martin

---

From: Mike Eisler <[email-masked]>
Date: Fri, 28 Apr 2000 08:50:29 -0700 (PDT)

> in the world and of the future can be assumed to look like the

I don't see the violation. "host" is just a string. RFC 2743 could
have selected any arbitrary string. All it is saying is that there is
well known target name that an application *may* use. nfs doesn't
use it it, ftp does, etc.

There's absolutely nothing that is Kerberos V5 specific about it.

>      are non-interoperable, we can only make things better.

NFSv4 since is specified to use LIPKEY. If NFSv4 is successful. i.e. there are
at least two independent interoperable implementations that fully conform to
all mandatory features of the protocol, including LIPKEY and SPKM-3, then
there will be two LIPKEY/SPKM-3 mechanisms that interoperate. At which time,
the specifications can be tightened.

> API implementations.  Interoperability on the wire is not enough,

TLS doesn't specify this, and interoperability is achieved. I don't see
why the fact that GSS-API is an API has anything to do with it.

> he should publish how it implements the authentication and maybe

As I've said before, I don't have an implementation.

> allow interoperable independent implementations to happen.

The above doesn't parse at all. Any proposed standard has an
implicit requirement to allow interoperable independent implementations.
You claim that the existing LIPKEY/SPKM-3 specification is insufficient
to allow multiple interoperable implementations to exist. You might be
right. However, until independent implementations are attempted, we
won't know, and when we know, we can update the LIPKEY rfc to further
specify the issues in question before advancing to Draft.

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Apr 2000 20:17:37 +0200 (METDST)

> the specifications can be tightened.

We're not discussing wire-protocol compatibility (which all SPKM gssapi
mechanism implementations have), we're discussion GSS-API level
application interoperability, more specifically the interoperability
of names/nametypes.  GSS-API is also an API, and LIPKEY a gssapi mechanism.

I suspect that your LIPKEY mechanisms will not interoperate on
server authentication, probably they will simply not authenticate servers.

> why the fact that GSS-API is an API has anything to do with it.

Because they don't care a penny about authentication.  They verify
signatures, verify certificate trust pathes and skip the authentication.

-Martin

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 28 Apr 2000 15:29:39 -0400

From: Martin Rex <[email-masked]>
   Date: Fri, 28 Apr 2000 15:39:43 +0200 (METDST)

No, not necessarily.  You're assuming that there will always being an
algorithmic transform from the GSSAPI service@hostname name form, and
the mechanism-specific low-level name format.

It may very well be the case that the mapping will require a database
lookup --- using LDAP, or consulting the MS Active Directory, or
whatever, to map [email-masked] to some X.509 name.

I don't think there's any assumption here that future mechanism's naming
architectures have to look like Kerberos of today.  It *does* mean that
in some cases gss_import_name may need to do a database lookup of some
kind, and that database lookup may require consulting a remote directory
over some kind of secure/trusted path.  Kerberos implementations hasn't
needed to do this up until now because of its relatively simple naming
structure, but to the extent that we need to deal with the secure DNS
issue, we may end up needing to consult some kind of secure directory as
well (whether it is secure DNS or some kind of LDAP server is really an
implementation issue, though, and not a protocol issue.)

It's up to the application protocol specification whether or not the
generic "host" service name should be used.  In some cases, such as
rlogin/telnet/ssh/etc., it really doesn't make any sense to have unique
identifies, since at some level, it's all the same service.  But for
other application protocols it doesn't make sense, in which case the
specification shouldn't make use of the generic "host" service.

That is arguably a difficiency in design and implementations the
non-Kerberos mechanisms, though, and not in the basic idea.  These sorts
of difficiencies can be addressed.

This kind of thing is important to get right.  If we don't have a
host-based service name, then trying to do GSSAPI mechanism negotiation
is *really* hard, since you now the application has to pass in the
target name before knowing which GSSAPI mechanism will be selected.

						- Ted