[1648] in Kerberos-V5-bugs
Re: telnet incompatability between V5b4pl3 and V5b5
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Sep 25 11:24:09 1995
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Your message of "Sun, 24 Sep 1995 17:17:29 EDT."
<9509242117.AA01446@dcl.MIT.EDU>
Date: Mon, 25 Sep 1995 11:24:01 EDT
From: Sam Hartman <hartmans@MIT.EDU>
Not copied to the submitter because this is more of an
informational query about the bug on my part than a fix.
>>>>> "o" == o <Theodore> writes:
o> Thank you for noticing this!! The behavior in Kerberos V5B5 is
o> wrong; B4pl3 is correct. We will be looking into fixing this
o> before we put out the next release.
o> - Ted
Did you actually find the problem yet? I was looking at the
code and I did find a problem that should prevent encryption from
working because the session key isn't properly stored after
mk_req_extended creates the subkey, but I don't see how it would
effect mutual authentication.
Basically, the beta-5 client sometimes (when ENCRYPTION
defined, as it normally isn't) selects the use_subkey option to
krb5_mk_req_extended. If I understand this option, it stuffs the
subkey into the authcontext and generated authenticator.
On the other side, rd_req then pulls the subkey out of the
authenticator and stuffs it into the auth context. If I understand
things correctly, the application doesn't have to do anything special
for this to happen.
Then, mk_rep should use whatever key is currently in the
authenticator, a subkey if one was present in the authenticator, and
the session key if one wasn't.
Back on the client side, since mk_req_extended made both the
authenticator and stuffed the auth context, the right key should be in
both places and everything should work when rd_rep is called.
I realize it may be a bug for beta-5 to not use a subkey all
the time, but I think this should still work in beta 4-3. I looked
briefly at the code, and it appeared even Beta 4 checked to make sure
the authenticator had a subkey before using it. (Beta 4 needs to
check this because it needs to pass the key explicitally to mk_rep if
a subkey is being used). Alternatively, there is a bug in the
library; I haven't checked this. Also, my check of the beta 4 code
was not completely thorough.
I'm curious if I'm understanding things correctly, and if
there are failure modes/aspects of the problem I'm overlooking.
--Sam
