On Fri, Sep 9, 2011 at 7:58 AM, Sam Hartman <[email protected]> wrote: > Rafa> Well, if we send a TGT or ST to the initiator, it would seem > Rafa> reasonable to me that initiator knows how to handle it. But > Rafa> maybe it is not reasonable. > > I agree that if the initiator is going to use a TGT or ST then it's fine > to assume it has code to deal with one. I think we may send a TGT or ST > to the initiator without being aware it can handle them; we could also > perform capability negotiation and confirm that the initiator can deal > with a TGT or ST before sending it. The capability option is desirable > if we want a different protocol.
You could just send it, in a wrap token embedded in a GSS-EAP context token. If the client can't use it, it won't, and that's that. Of course, this is wasteful of resources, particularly if the client does lots of GSS-EAP exchanges and doesn't grok Kerberos. So, yeah, this should be negotiated. (Awful, ugly thought: one might also allow for credential delegation whereby the acceptor gets a TGT and session key from the KDC through which to impersonate the initiator. How would the KDC learn that the initiator is willing to delegate credentials thus?) > In the case of the ST, it is often very useful to generate the ST and > hand the ST to the RP even if the initiator will never see the ST and > wouldn't know what to do with an ST if it had one. Why is this useful? A service ticket delivers a few features: a) the initiator principal's Kerberos principal name, b) any authz-data the KDC might want to put in the ST (though presumably GSS-EAP could deliver the same data as SAML, no?), c) the KDC signature on the ST, which enables S4U*. I think this is useful enough, but we should be careful to not make a KDC infrastructure a requirement for using GSS-EAP. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
