>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes:
>>
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.
Alejandro> I don't see why a user on possession of a valid ticket
Alejandro> for the application's realm should not be use it to fast
Alejandro> authenticate with it.
I want this, yes. However for the fast reauthentication use case it's
reasonable to assume initiator support.
Alejandro> I agree a different situation
Alejandro> would occur when the user does not have a TGT yet, but I
Alejandro> don't really see a big difference between starting a
Alejandro> Kerberos preauthentication (which will use GSS-EAP as
Alejandro> mechanism) or a direct GSS-EAP authentication. In the
Alejandro> usual Kerberos use case, the user has to "kinit" to
Alejandro> obtain the TGT, and that process may imply several round
Alejandro> trips as specified in RFC 6113.
I'm not worried about the round trips when the authentication succeeds.
The issue is what should the client application logic.
There are a lot of applications (and this is encouraged) for Kerberos
where the application tries fairly hard to use Kerberos if Kerberos is
offered by the server.
The assumption is a coupling of realms; the people who you talk to who
offer Kerberos are people you want to talk Kerberos to.
This affects retry behavior, affects whether you prompt users for
Kerberos passwords, etc.
This is an operational issue not directly a protocol issue.
It's a big deal though.
>>
>> 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.
Alejandro> I see your point, but anyway it does require the client
Alejandro> to support GSS-EAP. Why not adding a Kerberos dependency
Alejandro> for the support of the specific use case?
The deployment motivations are wrong.
The RP is the one who has the deployment insentive to share
infrastructure and better handle authorization
within the RP organization.
If making that work depends on something the client does, then it's a
lot harder to deploy because the client is not motivated to make
internal RP matters easier.
So, the RP would either have to have a fallback for clients that don't
support the option or would end up just not using the option.
>>
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.
Alejandro> Ok, thanks for the clarification. I understand now. I
Alejandro> thought that the KDC was including its own name in the
Alejandro> Acceptor Name RADIUS attribute.
If the KDC puts its own name in the acceptor name attribute, then the
channel binding will fail.
All this is possible for GSS-EAP, but it's starting to look kind of
complex in terms of generic gss-preauth:
1) We need the KDC to impersonate all RPs in its realm in terms of being
an acceptor for the GSS preauth mechanism.
Clearly possible for EAP but not say for a public-key mechanism.
2) We need standardized context tokens
3) We need keying such that there is some key only the KDC and client
know.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
