On Feb 23, 3:08 pm, Nicolas Williams <[email protected]> wrote: > On Mon, Feb 23, 2009 at 02:00:55PM -0800, Chris wrote: > > FWIW, I was slightly confused with the language in the GSSAPI RFC > > which seems to indicate that an implementation of a mechanism (e.g. > > Kerberos) is not necessarily compatible with that mechanism used on > > its own. [...] > > I suspect that may have been a reference to how the Kerberos V GSS-API > mechanism is not wire compatible with raw Kerberos V. Do you remember > what specific text you're referring to, and can you point me at it?
The main spot is in RFC 2743, near the end of section 1.1.3. Tokens: " The format of GSS-API tokens defined in conjunction with a particular mechanism, and the techniques used to integrate those tokens into callers’ protocols, may not be interoperable with the tokens used by non- GSS- API callers of the same underlying technique." I read that as suggesting that e.g. a Kerberos Ticket (including a TGT) obtained via native Kerberos calls might not be interoperable with GSS context- wrapped Kerberos tickets, so I wrongly assumed there must be some way to acquire a TGT via GSSAPI. Also, RFC 1964 section 3 throws me off a little - I thought the last sentence was saying that the mechanism should be implemented to request a TGT, but perhaps it's actually a directive for what the client application should do: "However, when the Kerberos V5 mechanism attempts to obtain initiating credentials for a service principal which are not available in a credentials cache, and the key for that service principal is available in a Kerberos V5 key table, the mechanism should use the service key to obtain initiating credentials for that service. This should be accomplished by requesting a ticket-granting-ticket from the Kerberos Key Distribution Center (KDC), and decrypting the KDC's reply using the service key." Chris ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
