Subject: Re: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Nov 2006 17:26:16 -0600

On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote:
> For some time, I had some difficult-to-articulate misgivings about the
> domain-based name concept advanced in these documents.  I now realize
> that the underlying issue is one of implicitly creating an
> authorization role where one might not have been present before.
> Essentially, the mere existence of a domain-based principal name forms
> an authorization assertion.

Yes.

>                              In Kerberos, and possibly other
> authentication architectures, the mere existence of a name does not
> usually express any authorization assertion.
> 
> For a traditional host-based service principal name, e.g.,
> "service_a@hostname_b", successful authentication to that service
> principal only implies that the administrator of the namespace has
> certified the association of some secret with the particular hostname
> (hostname_b), and that perhaps the administrator of "hostname_b"
> wishes to run an instance of "service_a" upon that host.

Indeed.

We're extending this very model.

> In contrast, the existence of a domain-based principal name such as
> "service_a@domain_b@hostname_c" constitutes an assertion that within
> the administrative domain defined for the namespace, the administrator
> of "hostname_c" is authorized to operate the specific service instance
> represented by the name "domain_b".

Correct.

> I think that users contemplating the use of these domain-based
> principal names should be cautioned that using such names will require
> re-evaluation of the policies followed by the administrators of the
> namespace, because the administrators must now consider that creating
> a principal name constitutes an authorization assertion, and the
> administrators may not have previously had the role of making
> authorization assertions.

So, then, it seems that you want a note cautioning realm administrators
that they must understand the purpose of any domain-based principal
which they create?  I believe that would be fair.

> I'm not sure this is the best textual description of the problem, but
> I think it does need to be discussed in the security considerations.
> The problem isn't sufficiently serious that it would be a bad idea to
> implement the domain-based principal name concept as described; it
> just would be a good idea to document the related security policy
> issues.

I believe: a) there is no problem, b) the problem that domain-based
naming solves is bigger than the problem you thinn.COM
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: secdir review of
	draft-ietf-kitten-gssapi-domain-based-names-03.txt and
	draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt
Reply-To: [email-masked]
Sender: [email-masked]
Resent-Date: Sat, 04 Nov 2006 00:09:11 -0500

On Fri, Nov 03, 2006 at 05:35:38PM -0500, Tom Yu wrote:
> For some time, I had some difficult-to-articulate misgivings about the
> domain-based name concept advanced in these documents.  I now realize
> that the underlying issue is one of implicitly creating an
> authorization role where one might not have been present before.
> Essentially, the mere existence of a domain-based principal name forms
> an authorization assertion.

Yes.

>                              In Kerberos, and possibly other
> authentication architectures, the mere existence of a name does not
> usually express any authorization assertion.
> 
> For a traditional host-based service principal name, e.g.,
> "service_a@hostname_b", successful authentication to that service
> principal only implies that the administrator of the namespace has
> certified the association of some secret with the particular hostname
> (hostname_b), and that perhaps the administrator of "hostname_b"
> wishes to run an instance of "service_a" upon that host.

Indeed.

We're extending this very model.

> In contrast, the existence of a domain-based principal name such as
> "service_a@domain_b@hostname_c" constitutes an assertion that within
> the administrative domain defined for the namespace, the administrator
> of "hostname_c" is authorized to operate the specific service instance
> represented by the name "domain_b".

Correct.

> I think that users contemplating the use of these domain-based
> principal names should be cautioned that using such names will require
> re-evaluation of the policies followed by the administrators of the
> namespace, because the administrators must now consider that creating
> a principal name constitutes an authorization assertion, and the
> administrators may not have previously had the role of making
> authorization assertions.

So, then, it seems that you want a note cautioning realm administrators
that they must understand the purpose of any domain-based principal
which they create?  I believe that would be fair.

> I'm not sure this is the best textual description of the problem, but
> I think it does need to be discussed in the security considerations.
> The problem isn't sufficiently serious that it would be a bad idea to
> implement the domain-based principal name concept as described; it
> just would be a good idea to document the related security policy
> issues.

I believe: a) there is no problem, b) the problem that domain-based
naming solves is bigger than the problem you think d-b naming has, c)
other ways of solving that bigger problem would be much more
heavy-weight than d-b naming.

That said, I don't mind adding security considerations text as described
above.  I'll write some up and post it.

Note that folks can and, I bet, have used Kerberos V's multi-component
principal naming feature to support naming conventions similar to the
one in d-b naming, thus this would seem like a generic security
consideration for any network authentication scheme with user-extensible
naming.

Nico
-- 

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

---

From: Tom Yu <[email-masked]>
Date: Fri, 03 Nov 2006 17:35:38 -0500

I have reviewed draft-ietf-kitten-gssapi-domain-based-names-03.txt and
draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt for the
security directorate.  For the most part, I do not see any serious
security issues, but I do think the security considerations should be
expanded.

an authorization assertion.  In Kerberos, and possibly other

I'm not sure this is the best textual description of the problem, but
I think it does need to be discussed in the security considerations.
The problem isn't sufficiently serious that it would be a bad idea to
implement the domain-based principal nai, 03 Nov 2006 17:35:38 -0500
Cc: 
Subject: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt
	and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt
Reply-To: [email-masked]
Sender: [email-masked]
Resent-Date: Sat, 04 Nov 2006 00:09:08 -0500

I have reviewed draft-ietf-kitten-gssapi-domain-based-names-03.txt and
draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt for the
security directorate.  For the most part, I do not see any serious
security issues, but I do think the security considerations should be
expanded.

an authorization assertion.  In Kerberos, and possibly other

---Tom

me concept as described; it
just would be a good idea to document the related security policy
issues.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 6 Nov 2006 23:42:45 -0600

> > wishes to run an instance of "service_a" upon that host.

Actually, it goes further than that.  Users typically know of hostnames,
as in URLs that they remember.  And these may be for sensitive services,
to which they'd send sensitive data.

Consider an application that, even when using network authentication
services to authenticate users, wants users to provide additional
authentication in the form of cleartext passwords.  For example, an
application for administering employee payment options (direct deposit,
tax deductions claimed, retirement account funding, etc...).  Users will
generally know the service by name, so the name of the service is quite
significant -- users trust that name if their browser indicates that it
has been authenticated.  So realm administrators had better know the
significance of the hostnames for which they issue long-term hostbased
service credentials.  Users perform a mental authorization step.

> We're extending this very model.

But not in a fundamental way.  Therefore I now reject the need for any
further security considerations text.

If the WG believes any such text is need, however, here's what I would
propose adding to the Security Considerations of draft-ietf-kitten-
gssapi-domain-based-names-03.txt:

   Note that, as with all service names, domain-based service names
   convey meaningful information that may be used for access control by
   initiators, therefore administrators of distributed authentication
   services should be aware of the significance of the service names for
   which they create acceptor credentials.

Nico
--