Subject: [Fwd: 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: Jeffrey Altman <[email-masked]>
Date: Mon, 06 Nov 2006 08:06:19 -0800

The attached messages were the result of a Security Directorate review
of draft-ietf-kitten-domain-based-names-03.txt and
draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt.

Nico will post to the Kitten mailing list the proposed Security
Considerations text when it is ready.

Jeffrey Altman

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]>
To: Tom Yu <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 3 Nov 2006 17:26:16 -0600
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>

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

Subject: secdir review of draft-ietf-kitten-gssapi-domain-based-names-03.txt and draft-ietf-kitten-krb5-gssapi-domain-based-names-03.txt
From: Tom Yu <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 03 Nov 2006 17:35:38 -0500
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>

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.

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

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

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.

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.

---Tom

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