I agree that this is a desirable use case. I think this can be generalized though, via an IAKERB-like GSS mechanism. Let me sketch it that way and then see if we can make incremental changes to GSS-EAP instead of pursuing a generic solution.
What I have in mind is a pseudo-mechanism -- think of it as a stackable pseudo-mechanism. It needn't actually be that generic if that's a problem for you. The pseudo-mechanism would add a bit of framing to the initiator's initial security context and channel binding data by which to bear the name of the RP, while the inner context tokens would be targeted at a different RP: the KDC in this case. Ah, but the initiator would have to learn the name of the inner context's RP (the KDC, or rather, realm name), and this would either require a host2realm facility like we have in most Kerberos clients, or an extra round-trip (and trusting the RP); we wouldn't wan the extra round-trip. On the acceptor side all context tokens would be proxied to the KDC over a tunnel authenticating the RP to the KDC, and then the KDC would give the RP an exported security context token. So that's the generic sketch. A non-generic set of changes for GSS-EAP would look the same, only without a different mechanism OID and without the generic pseudo-mechanism in the way. Note that you'll need the RP to be able to tell the KDC about the CB data affix -the RP's name as seen by the initiator- or have the KDC figure it out from the context (the armor key for the FAST tunnel). Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
