On Tue, Sep 6, 2011 at 6:19 PM, Sam Hartman <[email protected]> wrote: > Nico> c) Add some AS-REQ flags so that the AS-REP will contain an > Nico> pre-auth element that contains a KRB-CRED in it with the > Nico> desired tickets. In this case the enc-part of the AS-REP will > Nico> be useless and will be thrown out. > > Nico> d) Add some AS-REQ flags so that the AS-REP's pre-auth method > Nico> data will contain an embedded KRB-CRED (in the case of GSS > Nico> pre-auth probably using the Null enctype and embedded in a > Nico> wrap token). > > I don't see the difference between C and D.
I do. In (c) the RP has to collect the additional PA and bundle it in. In (d) the PA method at the KDC end-point takes care of that. Less abstraction violation in the RP -> better. > Also, this all seems like it focuses on the part of the problem where I > see lots of options rather than the part of the problem I don't know how > to deal with. > Namely, I don't understand how to make the key hierarchy work out right > across the gss-preauth boundary without either > > 1) building Kerberos knowledge into the initiator > > 2) having the acceptor gain the TGT key. The initiator MUST have a Kerberos client, else it MUST use a trusted proxy wherever Kerberos is required. I've no interest in building a trusted proxy here. So the question really is: what kind of violence to the initiator might we accept? Now, imagine for a second a variation on GSS_Init_sec_context() specifically for IAKERB-like mechanisms that outputs... a credential handle, just like GSS_Accept_sec_context does... The KRB-CRED included in a wrap token embedded a GSS-EAP token from the acceptor (really, the KDC), would be suitable for constructing such an output credential handle. The initator app would then GSS_Store_cred(), if it cares to. Or, when the app uses the original GSS_Init_sec_context(), the mechanism or the mechglue could just do it for the app according to local policy. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
