[4113] in Kerberos-V5-bugs
[krbdev.mit.edu #1415] subkeys fubar
daemon@ATHENA.MIT.EDU (Public Submitter via RT)
Fri Apr 18 00:14:11 2003
Date: Fri, 18 Apr 2003 00:14:01 -0400 (EDT)
Mail-Followup-To: rt@krbdev.mit.edu
Message-Id: <rt-1415-5768.10.3161975860181@krbdev.mit.edu>
In-Reply-To: <rt-1415@krbdev.mit.edu>
From: "Public Submitter via RT" <rt-comment@krbdev.mit.edu>
Mail-Copies-To: never
To: tlyu@MIT.EDU
cc: krb5-prs@MIT.EDU
Reply-To: rt-comment@krbdev.mit.edu
Errors-To: krb5-bugs-bounces@mit.edu
[tlyu - Thu Apr 17 19:51:38 2003]:
> Changing the default subkey negotiation doesn't break the
> AP-REQ/AP-REP exchange, since those messages only contain ciphertext
> encrypted using the ticket session key. They may break the state of
> what applications are expecting in terms of local and remote subkeys,
> though.
Right. I think the existing behaviour has to remain the default.
> To achieve "server subkey wins", we sould have to stomp on
> local_subkey in the client and on remote_subkey in the server. This
> might cause pointer aliasing nastiness, but is very probably
> manageable, given that the structure involved is supposed to be
> opaque.
Er, why can't server subkey wins (or any other variation) be a
per-auth-context
option that can be set by the application, with the current
ignore-the-server's-
offered-subkey behaviour as the default?
Nico
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs
