Subject: RE: GSSAPI service registry

From: "Linn, John" <[email-masked]>
Date: Tue, 10 Feb 1998 11:44:08 -0500

Chris Newman wrote, excerpting:

> On Fri, 6 Feb 1998, Linn, John wrote:
> > In addition to the entries now in the preliminary registry, FTP
> security
> > (RFC-2228) also specifies "ftp" as first-use value with optional
> > fallback to "host".  There'd been discussion, though I'm not now
> sure
> > where/if it had been documented elsewhere, of encouraging use of
> "host"
> > as a more generic successor to "rcmd", for those cases where a
> single
> > host-based service name is applied (in all or selective cases) with
> > scope broader than an individual protocol.
> 
> I do see the appeal of using "host" as "the fallback service name
> referring to all services at the host."  But this is a pretty serious
> interoperability issue, since it impacts all implementations of all 
> servers and clients which use the host-service name form. I don't
> think
> it's appropriate to make an incompatible change to the RFC 2228
> fallback
> rule from "ftp" to "rcmd" in a registry list.  If it's going to be
> done,
> it should be documented in a standards track RFC.
> 
RFC2228's reference to "rcmd" is confined to its Kerberos V4 section,
and I'm not sure that any standards-track reference exists to use of
"rcmd" with GSS-API.  RFC2228's GSS-API section specifies the fallback
as "host", and 2228 is Proposed Standard.  This is a matter with impact
broader than ftp, though; if clarified within an RFC, this should be
done in 2078bis, since that's where the cross-mechanism host-based
service name type is defined.  2078bis is currently silent on the
service element's values, deferring to IANA registry.  I'd like to hear
opinions on the three apparent choices:

- leave 2078bis silent on the topic

- change 2078bis to recommend/require "rcmd" as the service element's
value for a host-based service name corresponding to multiple protocols

- change 2078bis to recommend/require "host" as the service element's
value for a host-based service name corresponding to multiple protocols

> >  Since it doesn't seem to
> > offer much utility to be able to derive the protocol-specific name
> that
> > should be used to connect to a particular protocol's server absent a
> > definition of how GSS was integrated into that protocol, I'm
> thinking
> > that the GSS-specific registry (perhaps subdivided into per-protocol
> vs.
> > cross-protocol entries, and hopefully we won't need many more of the
> > latter) seems usefully clarifying.   What do others think?
> 
> Sounds reasonable to me.  While cross-protocol service names don't
> bother
> me, cross-service service names are a serious interoperability issue
> in
> my book.  Seems like somebody needs to write some proper IANA
> considerations for 2078bis, and probably define "host" there.
> 
I'm not fully clear on the distinction being drawn here.  For
"cross-service" as used here, is it safe to paraphrase with
"cross-mechanism" in the GSS sense or, if not, what's intended?  In any
case, the idea of 2078bis IANA considerations, and discussion of "host"
there, strikes me as appropriate.

> 		- Chris
	--jl

---

From: Chris Newman <[email-masked]>
Date: Tue, 10 Feb 1998 10:40:54 -0800 (PST)

On Tue, 10 Feb 1998, Linn, John wrote:
> "rcmd" with GSS-API.

I think "rcmd" with GSS-API should be reserved for remote command exection
services, such telnet, krlogin, krexec, krsh, ssh shell service, etc.  I'm
glad to see it's only suggested as a fallback for Kerberos 4 usage with
ftp.  The days when it is desirable to offer full login privileges to
general users of a server which offers some other service are numbered,
IMHO.

> value for a host-based service name corresponding to multiple protocols

Sounds good.

> > While cross-protocol service names don't bother
> > in my book.
> "cross-mechanism" in the GSS sense or, if not, what's intended?

I see cross protocol as the original intent of "rcmd" -- it's used for
multiple protocols which offer effectively the same service (e.g. krsh,
telnet). In general, I think this is a good thing.  It would be nice if we
had a "rfile" service rather than separate "nfs" and "foofs" services for
different remote filesystems.  Cross protocol services group protocols
with similar security risks and usage characteristics.  They're good
because they decouple the service offered from the way the service is
offered, thus simplifying management. 

Cross service names like "host", however, require all clients and servers
to probe for the right service name.  This sort of thing makes code slower
and clunkier.  I don't think we want a lot of these, and they really need
to be documented in standards track specs.  It shouldn't be possible to
create new umbrella services by adding a registry entry.

This implies that a registered service name MUST either be in a standards
track document, or refer to a protocol or set of protocols for which no
other specific service name applies.

		- Chris

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 10 Feb 1998 15:21:10 -0500

>value for a host-based service name corresponding to multiple protocols

Since 2078bis is already silent on the issue of service names, it seems
to make sense not to change that (because I think that the issue of
naming is outside of the scope of 2078bis, yes?)  If I had to vote for
either of the last two, I would vote for "host", since the two most
popular GSS-API bindings (Kerberos 5 and DCE) use "host" for this purpose
already.  AFAIK "rcmd" is used only for Kerberos 4, and there isn't
a Kerberos 4 GSS-API binding that I know of.

--Ken

---

From: Chris Newman <[email-masked]>
Date: Tue, 10 Feb 1998 14:02:51 -0800 (PST)

On Tue, 10 Feb 1998, Ken Hornstein wrote:
> The flip side is: does it make sense to use more than one service name
> per host at all?

Speaking as an applications vendor, I'd consider using "host" everywhere
to be the 99% case and using a service-specific name elsewhere to be the
1% case.  However, that 1% case can't be ignored.  Here are two examples
of real-world use (not necessairly in the GSSAPI context): 

I am aware of real customers who have requested service-specific
passwords.  They don't want their login password to be the same as their
mail password.  Having the concept of a service name is important to
support these customers.  This might also be important if, for example, I
have a users who use APOP and use separate passwords for that than for
interactive login.  Given that APOP requires the password to be
effectively in the clear on the server, this might be very important. 

The CMU Cyrus IMAP server does not run as root.  This means even if
there were a buffer overrun bug, it would not compromise the host if
attacked.  Unlike the "other" free IMAP server, Cyrus never had the
well-publicized bug which permitted root access to the server.  Cyrus also 
supports Kerberos 4 and has its own crontab file with the "imap" service.

Finally, we have a legacy situation -- the "host" concept is not
documented for any protocol other than "ftp."  This means that
compliant servers and clients written to the IMAP, POP, LDAP and ACAP
specs might not fall back to "host."  You're not allowed to declare
compliant implementations non-compliant without a *really* good reason in
the applications area.

		- Chris

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 10 Feb 1998 16:08:19 -0500

Let's use one example: ftp.

The current version of ftp distributed with Kerberos 5 can either
use "host" or "ftp" as the service name.  I diligently started creating
"ftp" principals at first to go along with the "host" principals, but
after a while, I wondered why I was bothering.  It just increased
the number of keys I had to manage.  I went through and got rid of
them all, and life has been easier.

>and clunkier.

Well, I don't know about that.  I don't really see the difference between
using "host" and using "rfile", except that one has five letters and one
has four.

Now probing for _multiple_ service names is complicated, I admit ... but
I'm not sure of the need.  ftpd, imapd, popper, nfsd/mountd ... they all
run as root, and can read the "host" service key as easily as they can
read the ftp, imap, pop, or nfs serice keys.  So perhaps a better meaning
of the "host" name is "all services that require root access and run on
that host".  Looking at things from that point of view ... do you need
that many different service names in practice?

Now, I've heard the argument that perhaps you'll want to run ftp under
a non-root account that won't be able to read host's key ... but I'm
wondering if anyone actually does that in practice?  I've Kerberized a
number of programs we use locally, and I created separate service names
for them ... but I'm wondering now if I should have bothered.

I am of course speaking from a Kerberos 5 point of view .... so I'd be
glad to hear from people who are using other GSS-API mechanisms, or
from people who think I'm just a total idiot in general :-)

--Ken

---

From: Sam Hartman <[email-masked]>
Date: 10 Feb 1998 17:36:24 -0500

>>>>> "Linn," == Linn, John <[email-masked]> writes:

    Linn,> Chris Newman wrote, excerpting:

    Linn,> - change 2078bis to recommend/require "rcmd" as the service
    Linn,> element's value for a host-based service name corresponding
    Linn,> to multiple protocols

	I do not think this would be a good idea.  At least for those
of us familiar with Kerberos, rcmd tends to be linked to a particular
protocol used by klogin and krsh to authenticate a connection.  The
generalization to telnet and other services probably initially
happened for administrative convenience.

    Linn,> - change 2078bis to recommend/require "host" as the service
    Linn,> element's value for a host-based service name corresponding
    Linn,> to multiple protocols

	I think this would be a reasonable choice.  The only
reservation I have is that there may be services that can be run with
less privelege and it may be desirable to restrict these services from using the host key in systems like Kerberos.  I would like to see a general practice develop where a service-specific name is tried and if that fails, a general name like "host" is tried.  Actually the order is unimportant; trying host first might be a good idea.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 10 Feb 1998 17:12:33 -0500

>[...]

Fair enough; seems like enough precedence to me.

>compliant implementations non-compliant without a *really* good reason in

Ah, I see ... you're worried that the "host" fallback might be required
for all GSS-API services.  I agree, that wouldn't be cool.

On a completely different subject ... am I the only one who is getting
these "Lotus Pager Gateways" emails to every message that they send
to cat-ietf?  A sample message is appended.  Can someone _please_ find
out who is doing this and make them stop?

--Ken

Subject: Re: Re: GSSAPI service registry (Sent to: Notes_Calgary Pager)
From: [email-masked]
To: [email-masked]
Date: Tue, 10 Feb 1998 14:57:51 -0600

To:       [email-masked]
cc:       [email-masked]
From:          [email-masked]
Date:          2/10/1998
Time:          15:21:10
Subject:  Re: GSSAPI service registry

Priority:
--------------------------------------------------
Message history for recipient Notes_Calgary Pager
Tuesday  10 Feb 1998  14:53:31 Mountain Standard Time - Message received by
Pager Gateway
Tuesday  10 Feb 1998  14:57:30 Mountain Standard Time - Message received by
Paging Service

---

From: Sam Hartman <[email-masked]>
Date: 10 Feb 1998 21:05:40 -0500

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    Ken> Now probing for _multiple_ service names is complicated, I
    Ken> admit ... but I'm not sure of the need.  ftpd, imapd, popper,
    Ken> nfsd/mountd ... they all run as root, and can read the "host"
    Ken> service key as easily as they can read the ftp, imap, pop, or
    Ken> nfs serice keys.  So perhaps a better meaning of the "host"
    Ken> name is "all services that require root access and run on
    Ken> that host".  Looking at things from that point of view ... do
    Ken> you need that many different service names in practice?

	In the Unix world, I would probably agree with you.  But even
there, I would be unwilling to run most imap implementations as root,
and would probably hack the source to run with less privilege.  I
agree that using one key for root services is perfectly reasonable as
an administrative policy.  I just don't think that the IETF should be
mandating or even recommending what sites run as root.

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 11 Feb 1998 17:07:01 -0500

Date: Tue, 10 Feb 1998 15:21:10 -0500
   From: Ken Hornstein <[email-masked]>

Unfortunately this convention never did get documented in the RFC's, but
the convention of using of "host" to mean host-based service name
actually predates GSSAPI's as an IETF standard; this was something that
we discussed when MIT and Digital were negotiating about using the
GSSAPI as a common interface for Kerberos and SPX.  So I would vote for
the use of "host" not because it is Kerberos-specific, but because it is
a much nicer generic name, and because the history of using "host" to
mean host-based service name goes back many years.

In contrast, "rcmd" is extremely Kerberos V4 specific.  "rcmd" means
nothing except to people who understand Kerberos V4, whereas "host"
actually has a meaning to those of us who speak English.  :-)

						- Ted