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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.