El 10/11/11 11:09, Sam Hartman escribió:
"Alejandro" == Alejandro Perez Mendez<[email protected]> writes:
>> [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.
Alejandro> Would be acceptable to support Kerberos on the client
Alejandro> side?
Alejandro> If so, then I think this model (or a very similar one)
Alejandro> could be supported by Moonshot by relying in IAKERB and
Alejandro> draft-perez-abfab-eap-gss-preauth. The initiator (client)
Alejandro> authenticates with the KDC by means of GSS-preauth +
Alejandro> GSS-EAP. The transport of the Kerberos messages is done
Alejandro> throught the RP, which at the end will obtain the ST with
Alejandro> the corresponding authorization information. This way
Alejandro> GSS-EAP is being used for federated authentication while
Alejandro> the KDC is being used for local realm authorization.
No, not really.
I see lots of reasons why I don't think this works.
The biggest in my mind is that the client behavior I'd recommend for
Kerberos is different than what I'd recommend for GSS-EAP.
Kerberos is something that clients tend to try and use whenever it is
available.
They assume it will fast-fail if it is the wrong option for a given
authentication.
That's not really true for something Federated.
I don't see why a user on possession of a valid ticket for the
application's realm should not be use it to fast authenticate with it.
I agree a different situation would occur when the user does not have a
TGT yet, but I don't really see a big difference between starting a
Kerberos preauthentication (which will use GSS-EAP as mechanism) or a
direct GSS-EAP authentication. In the usual Kerberos use case, the user
has to "kinit" to obtain the TGT, and that process may imply several
round trips as specified in RFC 6113.
Also, this needs to behavior that doesn't require client-side support so
that you can't end up with clients that don't support it.
It would be OK to add mandatory behavior to
draft-ietf-abfab-gss-eap. However I definitely don't want to end up
with clients that don't support whatever we end up with here.
I see your point, but anyway it does require the client to support
GSS-EAP. Why not adding a Kerberos dependency for the support of the
specific use case?
Alejandro> What will be the RP from the point of view of the home
Alejandro> AAA/IdP? It should be the original RP (the application),
Alejandro> and not the KDC if you want to provide a full set of
Alejandro> attributes and you want the IdP to be able to determine
Alejandro> which privacy policies will be applicable to release
Alejandro> them.
In my model the client thinks it is authenticating to the RP, so the
RP's information is in the acceptor name RADIUS attributes. The KDC may
include other information, possibly convincing the IDP to release more
attributes to the KDC only some of which will be forwarded to this
RP. (Think constrained Kerberos delegation). Alternatively the IDP may
release only the attributes needed by this RP and the KDC may do
additional attribute queries as in your prototype. From a deployment
standpoint I don't like that model because it is desirable to minimize
cases where a KDC calls out to another domain, but if you need that
level of privacy it is the right approach.
Ok, thanks for the clarification. I understand now. I thought that the
KDC was including its own name in the Acceptor Name RADIUS attribute.
Regards,
Alejandro
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
