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