Session key extraction
lukeh at padl.com
Tue Dec 23 17:37:10 EST 2008
> The project proposal should be specific as to which subset of these
> plan to implement.
> Also, there's the question of what base OIDs to use.
True, currently they're under the PADL arc but I will change this.
>> All mechanism-specific APIs in GSS-API have been re-implemented in
>> terms of these to avoid abstraction violations.
> I'm not sure I understand.
The current MIT code exposes the mechglue context layout to the
Kerberos mechanism. This is an abstraction violation and will not work
with stacked mechanisms. Look, for example, at
gss_krb5_get_tkt_flags() in krb5_gss_glue.c.
>> Two additional APIs are defined, gssspi_set_cred_option() (which sets
>> an attribute on a credential) and gssspi_mech_invoke() (which is a
>> catch-all context/credential-handle-less mechanism for invoking a
>> mechanism-specific API).
> What's the 'spi' part of these names about?
That was your suggestion :-) I believe the idea was that APIs tagged
with gssspi_ were to be called by mechanisms only.
More information about the krbdev