Subject: Re: Last Call: Telnet Authentication Option to Proposed Standard

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Nov 99 9:06:40 EST

> The IESG <[email-masked]> writes:
> 
> > o Telnet Encryption: DES3 64 bit Cipher Feedback 
> > 	<draft-altman-telnet-enc-des3-cfb-01.txt> 
> > o Telnet Encryption: DES3 64 bit Output Feedback 
> > 	<draft-altman-telnet-enc-des3-ofb-01.txt> 
> 
> Do these make sense at all? Do they provide any better security than
> single des?
> 
> I haven't seen any discussion.
> 
> /Johan
> 

I'm not sure that I understand the motivation behind the question.
You are questioning the use of Triple DES but not the use of
CAST-128.  Both are stronger ciphers than single DES but only if you
have enough available key info.

When using the current Kerberos implementations there is only enough
key info a single DES key which is used in both directions.  Other
authentication methods provide enough key info for the 3DES to use
6 different DES keys with a Triple DES implementation (3 in each
direction). 

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked] (Johan Danielsson)
Date: 23 Nov 1999 16:15:11 +0100

Jeffrey Altman <[email-masked]> writes:

> CAST-128.

I'm questioning the use of DES3 in anything but EDE on outer CBC
mode. There is a paper by Eli Biham about other combinations, which
basically says that most of them are not much better than single DES.

Even though this paper doesn't talk about this specific use, it's not
obvious that it's more secure to use DES3 to generate random numbers
than it is to use single DES.

Has this case been analysed by anyone?

/Johan

---

From: uri <[email-masked]>
Date: Tue, 23 Nov 1999 11:47:42 -0500 (EST)

> basically says that most of them are not much better than single DES.

For encryption purposes DES3 should only be used in outer mode.
Not necessarily CBC... [It was a while since I read that paper,
but I don't think Eli succeeded cracking outer CFB or OFB. The
key (no pun intended :-) is not to do inner feedbacks which 
allow cryptanalyst to tear the DES3 engine apart.]

> Has this case been analysed by anyone?

No "formal" analysis that I know of. But...
Intuitively DES3 *is* a stronger PRNG than single DES. Whether this
improvement is worth paying performance price, depends on your apps.
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked] (Johan Danielsson)
Date: 23 Nov 1999 18:31:00 +0100

uri <[email-masked]> writes:

> Intuitively DES3 *is* a stronger PRNG than single DES.

I don't necessarily see why. Isn't the OFB cycle length
approx. 2^blocklen? This would mean that CAST128 wouldn't be any more
secure than DES either.

But then I'm no crypto expert.

/Johan

---

From: uri <[email-masked]>
Date: Tue, 23 Nov 1999 12:50:17 -0500 (EST)

Johan Danielsson says:
> approx. 2^blocklen? This would mean that CAST128 wouldn't
> be any more secure than DES either.

Because of increased difficulty attacking such a PRNG by
a cryptanalyst. Who for example, might have obtained a
plaintext of an intercepted datastream encrypted with
those pseudo-random numbers (as pseudo-one-time pad),
and may now try to deduce the key to crack the PRNG
open (to decrypt the rest of this communication, or
to apply it to another one, or...).

Don't think "designer" - think "attacker".  Attacks can
be much more efficient/effective than hoping to exhaust
the cycle length. (:-)
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked]
Date: Tue, 23 Nov 1999 15:06:14 -0500

From: [email-masked] (Johan Danielsson)
   Date: 23 Nov 1999 16:15:11 +0100

The telnet encryption specification provides confidentiality but *not*
integrity guarantees.  It is using CFB/OFB because it is stream
oriented, and this *is* known weakness, and is discussed in the drafts.

Personally, I wouldn't have bothered with the triple-DES telnet
encryption mode, on the grounds that because it is a very weak mode, it
doesn't provide much protection.  However, Jeffery lobbied for them on
the grounds that they were being used in some existing implementations
(I don't remember which one, but it wasn't Kerberos V5), and that we
should document what some implementations are using today.

							- Ted

---

From: [email-masked] (Johan Danielsson)
Date: 23 Nov 1999 23:09:35 +0100

[email-masked] writes:

> However, Jeffery lobbied for them on the grounds that they were
> being used in some existing implementations (I don't remember which
> one, but it wasn't Kerberos V5), and that we should document what
> some implementations are using today.

I'm all for documenting things. What I'm trying to say is that there
might be a danger in having situations where people think that just
because it's using DES3 it's three times as secure, which might not be
the case.

/Johan

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 23 Nov 1999 23:18:59 +0100

>should document what some implementations are using today.
Protocols that offer increased complexity but no gain in security or 
efficiency over other standards-track efforts, but are in use today, are 
IMHO excellent candidates for Informational publication.

Not for the standards track.

                Harald A

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 23 Nov 1999 19:21:47 -0500

> Not for the standards track.
I'll go further.  THIS ENTIRE PROTOCOL DUPLICATES OTHER STANDARDS TRACK 
EFFORTS.  I see no reason why it should rise above Experimental and 
Informational.

We already have authentication and encryption at link layer (PPP), 
network layer (IPSec), transport layer (TLS), and session layer 
(SecSHell).  Why do we need application layer security, too?

If this were "just" authentication, just as new authentication modes 
have been added to protocols (POP3, SMTP) that already have some form of 
authentication, it might be useful.  But, Telnet has no extant 
authentication that is being improved.  This is a whole new set of 
features, including encryption (not mentioned in the announcement).  
Why bother?

Moreover, there is no _required_ option that must be implemented.  One 
of the most important interoperability design principles is violated.  

Finally, the protocol itself seems insecure and subject to denial of 
service and monkey in the middle attacks.  It's a bad idea.

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: [email-masked] (Johan Danielsson)
Date: 24 Nov 1999 10:21:09 +0100

> (SecSHell).  Why do we need application layer security, too?

This is another debate, but I would argue that it's *only* at the
`application layer' that encryption and authentication makes
sense. How can I trust IPsec when I don't know who's controlling the
keys? Encryption at other levels might have their own applications,
but it doesn't necessarily provide any explicit security to the end
user.

Anyway, the telnet encryption stuff has been in use for many years,
and this is just revival of some old drafts. They do have security
problems, and nobody would suggest a similar design today.

/Johan

---

From: Assar Westerlund <[email-masked]>
Date: 25 Nov 1999 08:20:17 +0100

> should document what some implementations are using today.

Shouldn't they be made informative rather than proposed standard in
that case?

/assar