Re: Federated realms and PAD

>>>>> "Nico" == Nico Williams <[email protected]> writes:

    Nico> The biggest problem with what you say Sam is that if it were
    Nico> correct then it would be an indictment against all existing
    Nico> multi-mechanism capable GSS-API applications, not just
    Nico> indictment of Kerberos.

I'm not going to address the  questions of what would it take to make
Kerberos federation-friendly.

It's a hard problem and it's not one I'm interested in solving at this
time: I have too much else going on.
(Well, trust routing for capaths is something I'm somewhat interested in
actually, but don't have a lot of time for.)

I'd like to start with responding to your tone.
Saying something is an indictment implies there's something wrong.
I don't think that's true at all.

I think the GSS-API is fine in this regard and to the extent I had
concerns about GSS-API I've already proposed solutions that kitten has
adopted.

I think Kerberos is fine. Kerberos doesn't have some
capabilities. That's OK: Kerberos never promised to be the only security
mechanism anyone would ever need.  Kerberos is great in many deployments
and is the widely successful enterprise security mechanism.

If you want to add capabilities to Kerberos that's fine; my plate's full
right now, but I'd be delighted if people want to enhance Kerberos.

There's nothing wrong with the PAD.  I actually think the PAD is easier
to specify and implement if it doesn't take on the full federated
context.

I don't think there's anything wrong with multi-mechanism GSS-API
applications.  We need to be careful in how we specify attributes to
make it possible to write these applications.  You shouldn't use the
same name for an attribute that should simply be trusted by an app as
for an attribute that contains similar data but requires the app to vet
it.  It's fine to map a requires vetting attribute into a just-trust-me
attribute if you've somehow done the vetting in a policy or
local-context specific manner.

Could we have done better with naming extensions?  Of course. Will we
find improvements we'd like to make in the future?  Probably.  However
what we have allows us to make significant forward progress so I'm
happy.

--Sam
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg