Encrypting krb_rced messages in GSSAPI tokens

[Nicolas.Williams@ubsw.com]

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.

Nico
--  

> -----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
>   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.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev
> 

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.