> >I was hoping for a mechanism such that > >* a TGT is generated if the initiator can take it > >* A service ticket is generated all the time > >* The service never knows the TGT key > >* The service always knows the context key > >* The initiator need not know about the service ticket side of the > business.
Sam, For the general case, what if: 1. The KDC supplies the context key to the RP within the protected pre-auth exchange. 2. GSS mechanism specific methods are defined for returning a TGT from the KDC to the initiator. 3. GSS mechanism specific methods are defined for deriving the TGT session key. In the particular case of GSS EAP: 1: the context key is derived from the EAP MSK per the spec today. The RP doesn't get to see the MSK. 2: the GSS EAP mechanism already provides for subtokens; and we have already implemented the case where a subtoken is a service ticket. Perhaps the same model could be extended to other mechanisms? 3: the KDC and initiator independently derive the TGT session key from the EAP MSK. The RP doesn't get to see the MSK. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
