Re: Federated realms and PAD
Nico Williams <[email protected]>
| Newsgroups | gmane.ietf.krb-wg |
|---|---|
| Message-ID | <CAK3OfOh=77swyS-WN1TLoqBoM57LP=ADtfD26bJmA5oOWZEkgQ@mail.gmail.com> |
The biggest problem with what you say Sam is that if it were correct
then it would be an indictment against all existing multi-mechanism
capable GSS-API applications, not just indictment of Kerberos.
There is some truth to what you say, and as you say it's more about
the attitude of people using Kerberos in specific cases than it is
about the protocols involved. But in cases where people are using
Kerberos with such an attitude and via GSS the problem affects your
EAP mechanism too (bear with me please).
In particular I would say that we're missing a few things to make
Kerberos meet your vague notion of federation:
- better policy expression mechanisms for applications
- including actually useful name attributes so that generic
policy might be implemented for GSS apps
But you're going to have the latter problem with any
GSS mech until we specify some name attributes.
And adding better policy to some mechs but not
others serves only to make GSS apps more mech-
specific.
- better policy expression mechanisms for TGSes for
cross-realm transits
- authz-data containers that allow us to make per-hop
statements about who issued what, and possibly using
digital signatures to authenticate each hop's statements
I'm not sure how much this is necessary. If trust chains
are short enough (zero transited realms, say), then it
isn't necessary at all.
- trust routing -- capaths suck, and so do hierarchical trusts
I think this is probably the single most important missing
piece in Kerberos for web scale deployment.
There's also no easy way to bootstrap short trust paths
from longer ones.
Also, I would very much like to hear your thoughts as to whether
Windows' Kerberos implementation is an exponent of the attitude you
describe. Active Directory has quite a few controls on trust, and PAC
filtering and so on (certainly more than MIT krb5).
Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg