Subject: Re: hostbased service names (or not)

From: Martin Rex <[email-masked]>
Date: Tue, 2 May 2000 13:13:28 +0200 (METDST)

Jeffrey Altman wrote:
> 
> > Your posistion:
> >   applications should enforce architecture and policies on sysadmins
> >   and gssapi mechanisms by requiring hostbased services names to work.
> > 
> > My posistion:
> >   gssapi mechanisms should be configurable for sharing credentials
> >   of services, and applications should be configurable for credentials
> >   and target names, so that the sysadmin and the users may freely
> >   choose among available gssapi mechanisms and determine their own
> >   policies (on sharing certain services credentials).
> 
> You are making a very bad assumption.  That GSSAPI is the only 
> authentication mechanism available to the application.  Its not.
> The application very frequently does have knowledge of policy that the
> underlying authentication mechansims do not have. 

Huh?  I didn't make assumptions.  I clearly stated that it should
be up to the sysadmin and user who installs gssapi with a particular
application to provide installation-specific policies and mapping.

In contrast, you want to put it into the application protocol spec,
and you want to force your own configuration onto every other installation
and environment by putting your own assumptions into the application
protocol spec.

-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: Martin Rex <[email-masked]>
Date: Tue, 2 May 2000 17:34:24 +0200 (METDST)

Theodore Ts'o wrote:
> 
> Well, my position is this: host-based service names should work so that
> the mapping between host/service pairs and mechanism names is done in
> one place --- at the mechanism layer, utilizing some kind of
> implementation specific database mapping layer which can be configurable
> by users and sysadmins for their particular site.  

That's almost what I've been asking for all the time.

However instead of leaving everything to the implementors,
there should be at least some guidance how to do this mapping
in the gssapi mechanism spec.

Some participants of the discussion only seem to care about the
configuration of their simple client apps.  I'm worring about the
configuration of our large distributed apps, where I think that 
it is very valuable being able to replace a particular Kerberos 5 library
with another one without having to worry about the 10000+ entries in
the ACLs of the application.  The only thing that you should have
to worry about is the exact procedure of making credentials
available to your application.

Given a clean mechanism spec, it doesn't matter whether whether the
new library is from a different vendor or simply an update from the
same vendor.  We have distributed applications running instances
of the same service on a large variety of platforms and we share
the ACLs across all of the hosts.  Sometimes you may not be able to get
a particular gssapi mechanism for all of your platforms from the
same supplier.

I know that there are vendors out there that like to tie you to their
products as much as possible, but IETF standards are traditionally
oriented towards interoperability.

> 
> This is absolutely necessary for simple GSSPAI mechanism negotiation to
> work, as I mentioned earlier.  It also concentrates the work necessary
> at the low-level mechanism level, so it only needs to be implemented
> once per mechanism, instead once for every GSSAPI application.

I consider the gssapi mechanism negotiation a different rathole.

Personally, I doubt that applications will in general not be prepared
to deal with mechanisms that do not share a unified namespace.
i.e. for applications, none of these three names are the same:

     "[email-masked]"    "[email-masked]"
     "CN=Martin Rex, O=SAP-AG, C=DE"

If individual names should refer to the same identity, then the
gssapi mechanism should provide the unified namespace, or once
again one will have to do it seperately for each application
instead of once per gssapi mechanism.

-Martin

---

From: "Linn, John" <[email-masked]>
Date: Fri, 5 May 2000 10:46:59 -0400

Martin wrote:

> Mike Eisler wrote:
> > 
> > > 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 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.
> 
> "host" is not just a string.  It is a particular notion of sharing
> credentials on a host by services that traditionally run under
> the root account of Unix machines.  For MIT Kerberos, the
> default acceptor credentials resolve to "host/f.q.d.n".
> (btw. rfc1964bis could also give some guidance on default
>  acceptor credential resolution).

While the use of "host" initially evolved as a reflection of UNIX root
practice, I don't think that the idea of a host-level identity, typically
representing an end system's OS rather than a particular application within
that system, is necessarily OS-specific. 

> 
> Just as each of the protocols rlogin,rexec,telnet as well as 
> ftp,nfs,ssh
> are assigned distinct well-known TCP-ports, they should be assigned
> distinct well-known hostbased service names.

I think this is appropriately a case-by-case judgment.  For the case of
closely-related application families (e.g, perhaps, (some of) rtools), it
may be appropriate for those families' designers to make the determination
that family members can be appropriately served by a common service
identity. 

> 
> Just because different application protocols offer essentially the
> same service doesn't mean that we should discriminate against gssapi
> mechanisms that do not offer to share credentials across processes.

In GSS terms, I don't think that what we're discussing here is actually
credential sharing across processes, but rather the ability to satisfy
multiple authorized processes' requests and thereby obtain for those
processes different credentials operating under the same identity.
Depending on the mechanism and implementation, this may result in more or
less sharing and indirection to underlying objects.  What's the state of
currently-implemented practice wrt ability to satisfy multiple processes'
requests for acceptor credentials under the same identity?

> 
> I think that requiring nfs@hostname for NFSv4 is the way 
> every application
> should do it.  

I think this usage is good practice in many cases, but (as noted) don't
believe that it needs to be mandated universally. 

Again, I strongly suggest that Kerberos gssapi 
> mechanism
> should be permitted to map "nfs@hostname" to the 
> "host/f.q.d.n" principal
> when the sysadmin wants this.

This mapping would be convenient operationally, but the principle could
complicate mutual authentication if applied in a general, cross-mechanism
sense: what rules should an initiator-side implementation follow to
determine whether an authenticated target identity acceptably matches the
name the originator requested, if the knowledge of mapping vs. non-mapping
is locally held only at the target?  

> 
> 
> > 
> > >    - 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.
> > 
> > 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.
> 
> Oh, that sounds interesting:
> 
> How do you verify that an implementation of LIPKEY and SPKM-3 conforms
> to the mandatory feature "all generic nametypes of rfc2078", when
> this part is not actually specified?

We have an IESG-approved document awaiting publication as Proposed Standard.
I think that we should proceed to trial implementations which will contain
support for the designated name types in some form, reflecting any further
refinement and agreements in successor or adjunct Internet-Drafts as the
process evolves.  I expect that further text on internal mechanism and
export name formats for LIPKEY will be likely results of this process.  

> -Martin

--jl