Re: Last Call: Telnet Authentication Option to Proposed Standard
[EMAIL PROTECTED] writes: > 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. Shouldn't they be made informative rather than proposed standard in that case? /assar
Re: Last Call: Telnet Authentication Option to Proposed Standard
At 17:35 23.11.99 -0500, Jeffrey Altman wrote: > > 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. > >I think the point of this debate is whether or not there is added >strength to the encryption. And so far the opinions have been >divergent. If 3DES is a better PRNG than DES then it is stronger. Indeed. Or rather: If draft-altman-telnet-enc-des3-[cfb,ofb] describes a mechanism where the best known attack is (significantly)more difficult than the best known attack on draft-tso-telnet-enc-des-[cfb,ofb], it should go to Proposed Standard (and the shoe is on the other foot; the -des- ones shouldn't go forward to Proposed, since DES-protected data is known to be vulnerable to brute force attacks). >As we point out in the Drafts, the telnet encryption stream mechanism >is susceptible to attacks. We know that. We have addressed it in >various ways. Unfortunately, the Telnet AUTH option implementations >for Kerberos 4, Kerberos 5, and Secure Remote Password all rely on the >Telnet Encryption option for privacy. I don't think it is appropriate >to send Telnet Auth to Proposed Standard with its reliance on an >option that is Informational. Hence, the desire for all of these >drafts to go to Proposed Standard. I'm not at the moment questioning whether draft-tso-telnet-encryption-04.txt should go to Proposed; the question hasn't been raised. I'm questioning the arguments for letting draft-altman-telnet-enc-des3-cfb-01.txt and draft-altman-telnet-enc-des3-ofb-01.txt should go to Proposed. >The TN3270 WG is working on a Telnet over TLS draft which has seen >several independent interoperable implementations for TN3270 and well >as more traditional telnet. My hope is to integrate Telnet over TLS >with Telnet AUTH so that Telnet AUTH may be used to provide mutual >authentication via a TLS using an ADH cipher. The one problem I have >run into is that the TLS Library vendors (other than OpenSSL) have >been very resistent to exporting the contents of the Finished messages >to the application so that they may be used in the Telnet Auth >negotiation to provide mutual authentication of the TLS. Once this >draft goes to Proposed Standard I would recommend that the Telnet >Encryption option be moved to Historical. But until that happens we >need it on the standards track. > >These drafts have been floating around the net for almost eight years >with many implementations. Its time for them to move on. If it is possible to satisfy RFC 2026 para 4.1.1: A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it. However, the IESG may waive this requirement in order to allow a specification to advance to the Proposed Standard state when it is considered to be useful and necessary (and timely) even with known technical omissions. Yes. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
> 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. I think the point of this debate is whether or not there is added strength to the encryption. And so far the opinions have been divergent. If 3DES is a better PRNG than DES then it is stronger. As we point out in the Drafts, the telnet encryption stream mechanism is susceptible to attacks. We know that. We have addressed it in various ways. Unfortunately, the Telnet AUTH option implementations for Kerberos 4, Kerberos 5, and Secure Remote Password all rely on the Telnet Encryption option for privacy. I don't think it is appropriate to send Telnet Auth to Proposed Standard with its reliance on an option that is Informational. Hence, the desire for all of these drafts to go to Proposed Standard. The TN3270 WG is working on a Telnet over TLS draft which has seen several independent interoperable implementations for TN3270 and well as more traditional telnet. My hope is to integrate Telnet over TLS with Telnet AUTH so that Telnet AUTH may be used to provide mutual authentication via a TLS using an ADH cipher. The one problem I have run into is that the TLS Library vendors (other than OpenSSL) have been very resistent to exporting the contents of the Finished messages to the application so that they may be used in the Telnet Auth negotiation to provide mutual authentication of the TLS. Once this draft goes to Proposed Standard I would recommend that the Telnet Encryption option be moved to Historical. But until that happens we need it on the standards track. These drafts have been floating around the net for almost eight years with many implementations. Its time for them to move on. - Jeff 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 PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
At 15:06 23.11.99 -0500, [EMAIL PROTECTED] wrote: >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. 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 PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
[EMAIL PROTECTED] 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
Re: Last Call: Telnet Authentication Option to Proposed Standard
From: [EMAIL PROTECTED] (Johan Danielsson) Date: 23 Nov 1999 16:15:11 +0100 > You are questioning the use of Triple DES but not the use of > 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. 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
Last Call: Telnet Authentication Option to Proposed Standard
>It is safer to use 3-DES than single Des because we use a 128-bit key >instead of a 64-bit key, so the number of possible keys is much bigger. Also >it has been reported that a method called 'match in the middle' could >penetrate the single -DES but not the 3-DES. > >-Original Message- >From: Jeffrey Altman <[EMAIL PROTECTED]> >To: Johan Danielsson <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; >[EMAIL PROTECTED] <[EMAIL PROTECTED]> >Date: Tuesday, November 23, 1999 4:24 PM >Subject: Re: Last Call: Telnet Authentication Option to Proposed Standard > > >>> Jeffrey Altman <[EMAIL PROTECTED]> writes: >>> >>> > You are questioning the use of Triple DES but not the use of >>> > 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 >>> >> >>Thanks for explaining. The answer is that I don't know. I am not >>qualified to make that analysis. >> >> >>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 PROTECTED] >> >> >> >
Re: Last Call: Telnet Authentication Option to Proposed Standard
It is safer to use 3-DES than single Des because we use a 128-bit key instead of a 64-bit key, so the number of possible keys is much bigger. Also it has been reported that a method called 'match in the middle' could penetrate the single -DES but not the 3-DES. -Original Message- From: Jeffrey Altman <[EMAIL PROTECTED]> To: Johan Danielsson <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Tuesday, November 23, 1999 4:24 PM Subject: Re: Last Call: Telnet Authentication Option to Proposed Standard >> Jeffrey Altman <[EMAIL PROTECTED]> writes: >> >> > You are questioning the use of Triple DES but not the use of >> > 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 >> > >Thanks for explaining. The answer is that I don't know. I am not >qualified to make that analysis. > > >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 PROTECTED] > > > 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 PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
> Jeffrey Altman <[EMAIL PROTECTED]> writes: > > > You are questioning the use of Triple DES but not the use of > > 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 > Thanks for explaining. The answer is that I don't know. I am not qualified to make that analysis. 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 PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
Jeffrey Altman <[EMAIL PROTECTED]> writes: > You are questioning the use of Triple DES but not the use of > 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
Re: Last Call: Telnet Authentication Option to Proposed Standard
> The IESG <[EMAIL PROTECTED]> writes: > > > o Telnet Encryption: DES3 64 bit Cipher Feedback > > > > o Telnet Encryption: DES3 64 bit Output Feedback > > > > 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 PROTECTED]
Re: Last Call: Telnet Authentication Option to Proposed Standard
The IESG <[EMAIL PROTECTED]> writes: > o Telnet Encryption: DES3 64 bit Cipher Feedback > > o Telnet Encryption: DES3 64 bit Output Feedback > Do these make sense at all? Do they provide any better security than single des? I haven't seen any discussion. /Johan