Encrypting krb_rced messages in GSSAPI tokens
Sam Hartman
hartmans at MIT.EDU
Mon Apr 29 16:55:01 EDT 2002
Traditionally, MIT has not encrypted the krb_cred message in the
GSSAPI token. This is a problem because it violates RFC 1510 and is
going to violate successor documents.
We've indicated here and on the IETF working group list that we plan
to continue not encrypting the krb_cred message for all our current
crypto systems (DES and 3DES) but to encrypt for future crypto
systems (AES, RC4, etc).
I'm not quite sure how to implement this. Currently, the code in
lib/gssapi/krb5/init_sec_context.c constructs the krb_cred before
calling krb5_mk_req_extended.
This is problematic because:
* The mk_req sets up the key and subkey in the auth_context
* the mk_cred needs these keys to encrypt
* The mk_req takes a structure containing the completed krb_cred as
input.
I'm not really sure how to handle this. The subkey is particularly
annoying because the subkey is generated randomly during the mk_req
call.
Thoughts would be welcome on how to restructure interfaces or
otherwise handle this issue.
More information about the krbdev
mailing list