[I think this is a Kerberos discussion mostly, but consider keeping
abfab in your reply if your discussion fits the abfab list.]
A month or so ago, I promised to write up a use case in response to an
abfab discussion having to do with obtaining a Kerberos ticket as a side
effect of a gss-eap preauthentication.
As background, Microsoft has a Kerberos mechanism called protocol
transition. The idea is that a service authenticates someone using a
non-Kerberos means. However, that service still wants to know what the
authorization characteristics of that user are.
In the Microsoft model, the KDC/directory are always responsible for
domain level authorization.
In order to obtain authorization information you need a security token;
to get one of those in a domain you generally need a Kerberos PAC.
There's a lot going for this model. It centralizes policy for the RP
organization in one place: the domain controller for the resource
domain.
We had several discussions at the MIT Kerberos Consortium's conference
last year about how valuable this is, and about how if we can maintain
this in the federated context, Kerberos could be an important policy
mechanism for the cloud.
I'd like Moonshot (the GSS-EAP implementation I'm working on) to be able
to support this model.
Would be acceptable to support Kerberos on the client side?
If so, then I think this model (or a very similar one) could be
supported by Moonshot by relying in IAKERB and
draft-perez-abfab-eap-gss-preauth. The initiator (client) authenticates
with the KDC by means of GSS-preauth + GSS-EAP. The transport of the
Kerberos messages is done throught the RP, which at the end will obtain
the ST with the corresponding authorization information. This way
GSS-EAP is being used for federated authentication while the KDC is
being used for local realm authorization.
One thing we can do is just use protocol transition as it's specified in
Microsoft's extensions today.
You do a GSS-EAP authentication to the RP, the RP asks the KDC for a
ticket, life goes on.
The problem with this is that protocol transition is relatively weak
from a security standpoint. The service makes an assertion to the KDC
that authentication happened.
This can be a privacy exposure to a certain extent: the service needs to
be trusted to obtain authorization information for any user who might
authenticate to it regardless of whether they have. Microsoft has
accepted this; some environments may not.
Another problem is that the resource domain controller may not have the
information needed to construct authorization information in a GSS-EAP
federation. SAML or RADIUS or Diameter information may be
necessary. Now, the KDC could trust the service to disclose the
information, or could possibly rely on SAML signatures.
Trusting the service that much seems a big stretch.
Relying on SAMl signatures viloates the one-trust-infrastructure design
principle. In particular, it's generally a bad idea for a security
system to force deployers to set up more than one trust infrastructure
because those are very expensive. If we're using GSS-EAP we already have
AAA trust. We should use that.
so, somehow, we need to get the KDC as a trusted intermediary in the
GSS-EAP authentication.
Note that we don't want to depend on any particular initiator
functionality. the RP needs to interact with the KDC for its own
purposes regardless of whether the initiator has ever heard of Kerberos.
I had originally thought about an EAP pre-authentication mechanism to
accomplish this goal. The idea is that gss-eap would take EAP packets
out of its incoming tokens and send them to the KDC as part of a
fast-armored AS-request. The client would be ambiguous--somehow
determined by preauth and the service would be the RP. The service
would not learn the MSK, but could be told the GMSK (GSS-EAP key).
What will be the RP from the point of view of the home AAA/IdP? It
should be the original RP (the application), and not the KDC if you want
to provide a full set of attributes and you want the IdP to be able to
determine which privacy policies will be applicable to release them.
Best regards,
Alejandro
If I could figure out a way to do this with gss-preauth and gss-eap then
I'd support gss-preauth.
Conceptually, I guess what's going on here is that you want to export a
context from the KDC and import it on the RP. However, we don't want to
expose the MSK to the RP so that if we are doing something that exposes
a TGT to the initiator we have a key to use.
So, this involves probably some changes to GSS-EAP and to the preauth
type. GSS-EAP probably needs to gain a standardized exported context
and the GSS preauth needs to gain a way to transfer an exported context
token if the mechanism supports the appropriate attribute.
Or something like that.
I'd appreciate comments on this use case and once we understand the use
case I'd like to talk about mechanisms for getting there.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
