Ticket History #656: telnet does not check for remote subkey during authentication

From fcusack@ratbert.iconnet.net Fri Nov 6 17:48:50 1998
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id RAA05922 for <bugs@RT-11.MIT.EDU>; Fri, 6 Nov 1998 17:48:49 -0500
Received: from ratbert.iconnet.net by MIT.EDU with SMTP
id AA28803; Fri, 6 Nov 98 17:48:50 EST
Received: (from fcusack@localhost)
by ratbert.iconnet.net (8.9.1/8.9.1) id RAA27554;
Fri, 6 Nov 1998 17:49:18 -0500 (EST)
Message-Id: <199811062249.RAA27554@ratbert.iconnet.net>
Date: Fri, 6 Nov 1998 17:49:18 -0500 (EST)
From: fcusack@iconnet.net
Reply-To: fcusack@iconnet.net
To: krb5-bugs@MIT.EDU
Subject: telnet does not check for remote subkey during authentication
X-Send-Pr-Version: 3.99

Icon CMT Corp.
N/A
System: SunOS ratbert 5.6 Generic_105181-09 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4

telnet client always uses local subkey as the encryption key
[for encrypted telnet sessions]. However, if the remote side
sends back it's own subkey, it should use that instead. Not
a problem against MIT telnetd, since the remote subkey is
always identical to the local, but other telnetd's may not
do the same thing.
I don't know of any telnetd's that actually do this, the problem
is not one that I have seen in actual use.
diff -u -r1.1.1.1 kerberos5.c
--- kerberos5.c 1998/10/14 00:47:33 1.1.1.1
+++ kerberos5.c 1998/11/06 22:33:24
@@ -319,22 +319,26 @@
}

if (newkey) {
+ /*
+ * XXX code previously was here to check enctype of subkey.
+ * Not needed - subkey will have same type as session key.
+ * [Assuming MIT libraries]
+ * This limits session key enctypes to DES for now.
+ */
/* keep the key in our private storage, but don't use it
yet---see kerberos5_reply() below */
- if ((newkey->enctype != ENCTYPE_DES_CBC_CRC) &&
- (newkey-> enctype != ENCTYPE_DES_CBC_MD5)) {
- if ((new_creds->keyblock.enctype == ENCTYPE_DES_CBC_CRC) ||
- (new_creds->keyblock.enctype == ENCTYPE_DES_CBC_MD5))
- /* use the session key in credentials instead */
- krb5_copy_keyblock(telnet_context,&new_creds->keyblock,
- &session_key);
- else
- /* XXX ? */;
- } else {
- krb5_copy_keyblock(telnet_context, newkey, &session_key);
- }
+ krb5_copy_keyblock(telnet_context, newkey, &session_key);
krb5_free_keyblock(telnet_context, newkey);
+ } else {
+ /* XXX Should we just continue with the session key? */
+ krb5_free_cred_contents(telnet_context, &creds);
+ krb5_free_creds(telnet_context, new_creds);
+ if (auth_debug_mode) {
+ printf("telnet: Kerberos V5: mk_req did not generate a subkey!\r\n");
+ }
+ return (0);
}
+
#endif /* ENCRYPTION */
krb5_free_cred_contents(telnet_context, &creds);
krb5_free_creds(telnet_context, new_creds);
@@ -581,6 +585,7 @@
{
#ifdef ENCRYPTION
Session_Key skey;
+ krb5_keyblock *newkey = 0;
#endif
static int mutual_complete = 0;

@@ -612,7 +617,8 @@
#endif /* ENCRYPTION */
}
if (cnt)
- printf("[ Kerberos V5 accepts you as ``%.*s'' ]\r\n", cnt, data);
+ printf("[ Kerberos V5 accepts you as ``%.*s'' ]\r\n",
+ cnt, data);
else
printf("[ Kerberos V5 accepts you ]\r\n");
auth_finished(ap, AUTH_USER);
@@ -639,13 +645,38 @@
return;
}
krb5_free_ap_rep_enc_part(telnet_context, reply);
+
#ifdef ENCRYPTION
+
+ /* Use remote subkey if one was returned */
+ krb5_auth_con_getremotesubkey(telnet_context,
+ auth_context,
+ &newkey);
+
+ if (newkey) {
+ if (session_key) {
+ krb5_free_keyblock(telnet_context, session_key);
+ session_key = 0;
+ }
+ if ((newkey->enctype != ENCTYPE_DES_CBC_CRC) &&
+ (newkey->enctype != ENCTYPE_DES_CBC_MD5)) {
+ printf("[ Telnet Encryption failed: remote subkey enctype unknown (%d) ]\r\n",
+ newkey->enctype);
+ krb5_free_keyblock(telnet_context, newkey);
+ return;
+ } else {
+ krb5_copy_keyblock(telnet_context, newkey,
+ &session_key);
+ }
+ krb5_free_keyblock(telnet_context, newkey);
+ }
+
if (session_key) {
skey.type = SK_DES;
skey.length = 8;
skey.data = session_key->contents;
encrypt_session_key(&skey, 0);
- }
+ }
#endif /* ENCRYPTION */
mutual_complete = 1;
}

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, fcusack@iconnet.net
Cc: hartmans@MIT.EDU, gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: telnet/656: telnet does not check for remote subkey during authentication
Date: Tue, 10 Nov 1998 04:22:37 GMT

Date: Fri, 6 Nov 1998 17:49:18 -0500 (EST)
From: fcusack@iconnet.net

telnet client always uses local subkey as the encryption key
[for encrypted telnet sessions]. However, if the remote side
sends back it's own subkey, it should use that instead. Not
a problem against MIT telnetd, since the remote subkey is
always identical to the local, but other telnetd's may not
do the same thing.
I don't know of any telnetd's that actually do this, the problem
is not one that I have seen in actual use.

I don't want to apply this patch, because to do so would imply a
protocol change. The protocol has always been that the client could set
the session key, but not the server. Kerberos V5 subsession key
semantics were never defined in RFC-1510, and while I don't like how
telnet negotiates the subsession key (if anything, it *should* be the
server that picks the key to be used for encryption, not the client),
changing it at this point would only cause massive interoperability
problems.

- Ted

From: Frank Cusack <fcusack@iconnet.net>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, hartmans@MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
Subject: Re: telnet/656: telnet does not check for remote subkey during authentication
Date: Tue, 10 Nov 1998 11:09:55 -0500

hmm... While RFC 1510 does not discuss subsession key negotiation,
the revisions-01 draft (now expired) does. Given that "no" implementations
actually have the server generate a new subkey, this patch should
be harmless, as long as telnetd continues to use the client key
(this patch does not change server behavior, only client).

In fact, if the server does generate it's own subkey, it probably
does want to use it (why else generate it?), so the existing telnet
client would not work. [Regardless of what's in RFC 1510.]

I assume that whenever a followup to 1510 comes out, it will have the
subkey negotiation discussion. So this would make telnet compliant,
and at the same time, existing implementations should work.

I can test this patch against the cybersafe and cisco telnetd's if
you like.

~frank

In message <199811100422.EAA28913@dcl>,
"Theodore Y. Ts'o" writes:



From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Frank Cusack <fcusack@iconnet.net>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU, hartmans@MIT.EDU,
gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: telnet/656: telnet does not check for remote subkey during authentication
Date: Tue, 10 Nov 1998 20:54:43 GMT

Date: Tue, 10 Nov 1998 11:09:55 -0500
From: Frank Cusack <fcusack@iconnet.net>

hmm... While RFC 1510 does not discuss subsession key negotiation,
the revisions-01 draft (now expired) does. Given that "no" implementations
actually have the server generate a new subkey, this patch should
be harmless, as long as telnetd continues to use the client key
(this patch does not change server behavior, only client).

.... and the language in revisions-01 draft is changing, because it's
broken.

In all cases, though, the only thing we can do in the RFC-1510 bis draft
is specify "default behaviour" for the subkey handling, and note that
individual application or protocol specifications (like telnet, for
example) can specify something other than the default behaviour, and
that will take priority over what's in RFC-1510 bis.

We have to retain backwards compatibility with older protocols and
implementations, and that means that if RFC-1510 botched the subkey
negotiation by not specifying a standard way of doing it, we can't go in
after the fact and add a standard way if it ends up breaking the current
deployed base.

- Ted

From: Frank Cusack <fcusack@iconnet.net>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, hartmans@MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
Subject: Re: telnet/656: telnet does not check for remote subkey during authentication
Date: Tue, 10 Nov 1998 16:25:28 -0500

In message <199811102054.UAA29301@dcl>,
"Theodore Y. Ts'o" writes:

agreed. My problem was I didn't see where the telnet behavior
was defined. But I just looked at draft-tso-telnet-krb5-00.txt...
which has expired. What are the implications of changing this draft
to match RFC1510bis? It could even say "servers should not generate
a new subkey if they want to remain compatible with older clients"
(although I would not be in favor of such language).

In the end, my point is that I don't think it would break any *existing*
implementations. New clients would work against existing servers,
and new servers could do what they do now -- don't create a new subkey.
I didn't read the subkey negotiation as "the server MUST create a new
subkey".

If in fact, existing implementations wouldn't break, (and I don't see how
they would) AND the telnet draft could be changed, I think it's a valuable
"fix".

Anyway, that's the last I'll comment.

~frank

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Fri Jan 22 00:51:04 1999
State-Changed-Why: Not a bug; maybe a design flaw in the protocol