[4156] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #1415] subkey fubar description
daemon@ATHENA.MIT.EDU (Tom Yu via RT)
Fri Apr 25 18:53:12 2003
Date: Fri, 25 Apr 2003 18:38:04 -0400 (EDT)
Message-Id: <rt-1415-5844.19.9980022942596@krbdev.mit.edu>
In-Reply-To: <rt-1415@krbdev.mit.edu>
From: "Tom Yu via RT" <rt-comment@krbdev.mit.edu>
To: krb5-prs@mit.edu
Reply-To: rt-comment@krbdev.mit.edu
Errors-To: krb5-bugs-bounces@mit.edu
First, clarification on my message of 20030416 -- (1) and (2) are
swapped in 1.0.x only for rd_safe/rd_priv, not mk_safe/mk_priv.
Conclusions from discussion yesterday with Sam and Ken:
There will be three subkeys stored in the auth_context: "subkey",
"send_subkey", and "recv_subkey" (or similarly named things).
"send_subkey" will be what "local_subkey" is now, and "recv_subkey"
will be what "remote_subkey" is now, except that they won't be set
anymore. New APIs may be written to allow the application to set
"send_subkey" and "recv_subkey".
On the client side, mk_req and rd_rep will set "subkey" only.
mk_safe/mk_priv will prefer "send_subkey", followed by "subkey".
rd_safe/rd_priv will prefer "recv_subkey", followed by "subkey".
In the future, new APIs will allow a client application to extract the
different subkeys by querying the subkey either after mk_req or after
rd_rep. mk_req will set "subkey" if requested, and send it in the
AP-REQ message. rd_rep will read the subkey from the AP-REP message,
and store it in "subkey", possibly overwriting one stored there by
mk_req.
On the server side, rd_req will set "subkey", and mk_rep may
eventually allow an application to set a new "subkey", which will also
be transmitted by mk_rep.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs
