>>>>> "Alejandro" == Alejandro Perez Mendez <[email protected]> writes:
>>
Alejandro> on the first place, to make the KDC Moonshot-enabled you
Alejandro> need it to support GSS preauth.
>>
>> Or define an EAP preauthentication fast factor.
Alejandro> I guess you meant GSS-EAP preauthentication fast factor,
Alejandro> right?
No.
Any preauth mechanism is a FAST factor.
So if there is a GSS preauth there is a GSS and thus GSS-EAP FAST
factor.
I mean go back to a model where it's EAP between the RP and KDC not GSS.
I've been thinking more about this. It's obvious to me that we don't
want to use the same GSS-EAP context between the client and RP that we
do between the RP and KDC, even if we use the same EAP conversation. My
rationale is a bit complicated. One of the big reasons is that the
question of which enctype to use, what GSS-EAP features to use etc
should depend on the RP capabilities not on the KDC capabilities. Also,
(and perhaps this is what Nico's getting at) it simplifies GSS channel
binding between the client and RP.
This doesn't mean we can't use GSS-PREAUTH; it just means using
GSS-PREAUTH is kind of complicated.
So, like Josh, I'm beginning to ask what GSS buys us in
preauthentication?
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
