> > Can you clarify for me who needs access to the shared key? Is this
> > something that the Kerberos libraries would need to be able to derive
> > from state that only it would have access to, or is it supplied from
> > outside to the relevant Kerberos library APIs?
>
> I'm not entirely sure what you're asking, but it sounds like an
> implementation-specific question.
What I mean is, does the message have to be encrypted with some key that
involves keying material that involves the KDC in any way, or is just
arbitrary to the standard for this message, but may not be arbitrary to
particular implementations? It sounds like the latter.
> * Unfortunately, krb5_get_forwarded_creds() is not actually a good API
> for this, as it also handles the details of getting forwarded tickets
> from the KDC. Since ticket forwarding is specified only for TGT's, this
> means this interface can only be used to forward a TGT, though the
> KRB-CRED PDU itself has no such constraint.
So actual implementations, pending enhancement of Kerberos libraries, might
need implementation specific code to translate the local credential cache
form into the PDU and back?
-- Scott
