Subject: Adding security considerations text to draft-ietf-kitten-gssapi-domain-based-names

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Jan 2007 14:49:20 -0500

In order to resolve Tom Yu's security directorate review we're
proposing the following additional security considerations text.
Please scream if you have any objections.

  "Note that, as with all service names, the mere existence of a
  domain-based service name conveys meaningful information that may be
  used by initiators for making authorization decisions; therefore,
  administrators of distributed authentication services should be
  aware of the significance of the service names for which they create
  acceptor credentials."

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Tom Yu <[email-masked]>
Date: Wed, 03 Jan 2007 20:46:00 -0500

An alternative which I prefer is the following:

  "With all service names, the mere existence of service name conveys
  meaningful information that may be used by initiators for making
  authorization decisions.  Domain-based service names make stronger
  authorization assertions than do simple host-based service names;
  therefore, administrators of distributed authentication services
  should be aware of the significance of the service names for which
  they create acceptor credentials."

I think it makes somewhat more clear that there is a qualitative
change in the responsibilities of the administrators of the
authentication infrastructure when domain-based service names become
deployed.

Quoting some prior private discussion:

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

Sam> Today MIT is very happy to hand out host, rvdsrv (don't ask),
Sam> daemon , discuss and a few other principals to anyone who can
Sam> demonstrate that they run a host.  The assumption is that having
Sam> such a principal doesn't say anything about the overall mit.edu
Sam> namespace; it is simply a service running on that host.

Sam> The first time you introduce a service whose clients expect the
Sam> service to be domain-wide, you need to make a new decision when
Sam> handing out a a key: is this principal allowed to speak for the
Sam> entire namespace.  It may be the case that ldap in current client
Sam> implementations actually already works this way even without the
Sam> domain based names draft.  But host and a number of other
Sam> services definitely do not.  The first time you add a domain
Sam> based service, you take on a new responsibility in namespace
Sam> management.  Previously you needed to ask whether you were giving
Sam> a key to the person responsible for the machine on which it runs.
Sam> You still need to ask that, but you also need to ask whether that
Sam> machine is allowed to represent the entire domain.