Subject: Re: hostbased service names (or not)

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

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

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.

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.

I think that requiring nfs@hostname for NFSv4 is the way every application
should do it.  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.

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

-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: "Theodore Ts'o" <[email-masked]>
Date: Mon, 8 May 2000 21:13:57 -0400

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

What GSSAPI mechanisms don't allow sharing of credentials across
processes?  It's just a matter of configuring any system so that each
process has access to the same set of cryptographic material (service
key in the case of Kerberos, private key in the case of an X.509
certificate, etc.).  

Whether or not the system is a Unix based system is really irrelevant to
the discussion --- the same applies whether you're on an NT system, or
any other OS.

Agreed, there should be a way for the system administrator to map
GSSAPI service names to actual kernel names.  The current default
behaviour isfine, but it should be overrideable by the sysadmin.

							- Ted