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 ProposedStandard
> 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. These options have been in use for eight years and are widely deployed. Telnet AUTH is currently RFC 1416. We are removing the man in the middle attack that is possible with that RFC. Please see my other postings to this thread for a discussion of TLS and Telnet. 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 ProposedStandard
Harald Tveit Alvestrand 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'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 PROTECTED] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
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
선교목적전도메일입니다
»çÀü¾çÇؾøÀÌ ¼±±³¸ñÀû Àüµµ-¸ÞÀÏ À» º¸³»µå·Á Á˼ÛÇÕ´Ï´Ù. ÇÊ¿äÇÏÁö ¾ÊÀ¸½ÅºÐÀº »èÁ¦ÇØÁֽðí, ÇÊ¿äÇϽźÐÀº ÀÌ°¥·¾¸ñ »çÀÇ °Çؼ³±³¸¦ ûÃëÇØÁÖ½Ã¸é °¨»çÇÏ°Ú½À´Ï´Ù. ¼³±³¸Þ½ÃÁöÀü¹® °¥·¾È¨ÆäÀÌÁö¿¡¼ º¸³»µå¸³´Ï´Ù(http://www.caleb3927.org)[GMA ÁÖ»êÇØ¿ø(ñ«ß£úê«)] ¡¡ - Real Audio Service Á¦°ø - 1. »õ õ³â¿¡ °®°í °¥ ¼¼±â ¸¶Áö¸· Ãß¼ö(Ãâ 12:29-36)[1999.11.21¹ã ¼³±³] 2. ¸¶À½¿£ ¿ÕÀÌ·ÎµÇ À°½ÅÀÌ ¿¬¾àÇÏ¿©(¿ÕÇÏ 5:17-19)[1999.11.14 ¹ã ¼³±³] 3. ÀÌ·¯ÇÑ ¶§¿£ ÁÖ²²¼µµ Á×À¸¼Ì´Ù #3 (â 3:11-14) [1999.10.31¹ã ¼³ ±³] 4. ÀÌ·¯ÇÑ ¶§¿£ ÁÖ²²¼µµ Á×À¸¼Ì´Ù #2 (º¦Àü 4:1-6) [1999.10.24¹ã ¼³ ±³] 5. ÀÌ·¯ÇÑ ¶§¿£ ÁÖ²²¼µµ Á×À¸¼Ì´Ù #1 (´ª 23:1-12) [1999.10.17¹ã ¼³ ±³] ¡¡ Áö±Ý Á¢¼ÓÇϽʽÿÀ Çϳª´ÔÀÇ ¸»¾¸ÀÌ ÀÌ°÷¿¡ ÀÖ½À´Ï ´Ù. http://www.caleb3927.org ¡¡
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]
Normative RFC references
Hi all,
What is the best way to deal with the RFC status in normative references?
Should I only use normative references on "Standard" RFC's although
"Proposed Standard" RFC's may already obsolete them and contain better
information?
Should I give a choice?
Example:
(Y = Proposed Standard, obsoletes X; X = Standard)
"If Y is implemented, use blabla as in Y. Otherwise, blabla must be
used as defined in X."
In my case, I am currently updating my draft "draft-welzl-ptp-01.txt"
which relies on MIB-II information; RFC2233, being a Proposed Standard
RFC, now offers a new object that certainly makes sense but will
not be available in all routers due to the RFC status. The version above
("if RFC2233 is implemented, ...") seems to be the best choice then,
doesn't it?
Regards,
Michael
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
