Encrypting krb_rced messages in GSSAPI tokens
Nicolas.Williams at ubsw.com
Mon Apr 29 17:16:00 EDT 2002
Suggestion: change mk_req_extended() (or make a new API) that takes a callback function pointer and make it so the callback function gets called with the ticket key and subkey blocks; the callback function should return data for use in the checksum field.
> -----Original Message-----
> From: Sam Hartman [mailto:hartmans at mit.edu]
> Sent: Monday, April 29, 2002 4:55 PM
> To: krbdev at mit.edu
> Subject: Encrypting krb_rced messages in GSSAPI tokens
> 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
> I'm not really sure how to handle this. The subkey is particularly
> annoying because the subkey is generated randomly during the mk_req
> Thoughts would be welcome on how to restructure interfaces or
> otherwise handle this issue.
> krbdev mailing list krbdev at mit.edu
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
More information about the krbdev