Options to make this happen: a) Make the GSS-EAP client aware of the AS exchange and give it the bits it needs to recover the reply key and extract the credentials. Now how to get a service ticket for the RP in a round-trip efficient way? Well, have the RP mint one and be done, say. Or define a new way to use a TGT as an additional ticket with which to get the desired service ticket (sortof like reverse user-to-user).
b) Define a new AS-like exchange where the final reply in a successful case contains a KRB-CRED, so that multiple tickets may be issued at once, then apply the solution above this one. c) Add some AS-REQ flags so that the AS-REP will contain an pre-auth element that contains a KRB-CRED in it with the desired tickets. In this case the enc-part of the AS-REP will be useless and will be thrown out. d) Add some AS-REQ flags so that the AS-REP's pre-auth method data will contain an embedded KRB-CRED (in the case of GSS pre-auth probably using the Null enctype and embedded in a wrap token). It all sounds rather messy to me. Desirable, yes, but also messy. (d) implies that the pre-auth plugin on the KDC must have access to all details of the AS-REQ. Probably not a big deal. It also implies that the pre-auth plugiin must have some way to get the desired tickets minted, which sounds like a fairly major abstraction violation, but one I could make peace with. (a), (b), and (c) would make GSS-EAP as a protocol have too much Kerberos knowledge for my comfort. I think (d) is the best option, then. The best part of this though is that it gives you a reason to want GSS pre-auth ;) Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
